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DISCLAIMER 

The  motivation  for  this  report  was  a request  from  the  Nuclear 
Regulatory  Commission  (NRC)  for  NBS  to  analyze  the  hardware,  software, 
and  file  structure  that  would  be  required  to  automate  selected  types 
of  data  for  a specific  application.  This  problem  was  analyzed  at  the 
NBS,  in  the  context  of  the  constraint  that  the  recommended  hardware 
and  software  would  have  to  be  compatible  with  that  in  use  at  the  NRC. 

Using  primarily  vendor  literature  and  the  experience  of  NBS  workers, 
several  commercially  available  database  management  systems  (DBMSs) 
were  examined.  The  DBMS  that  was  found  to  be  most  suitable  in 
relation  to  the  requirements  was  tested  to  verify  its  adequacy. 

This  report  identifies  various  hardware  and  DBMSs  by  trade  names,  as 
necessary  to  provide  a descriptive  characterization  of  their  features 
and  to  answer  a specific  request  on  costs  of  the  recommended  hardware 
and  software.  Neither  the  recommendations  nor  the  inclusion  of  any 
item  of  hardware  or  software  in  this  report  implies  a recommendation 
or  endorsement  by  the  National  Bureau  of  Standards  for  applications 
other  that  for  which  this  study  was  undertaken.  Further,  the  vendors 
were  not  asked  to  verify  information  for  accuracy  and  clarity,  and  the 
recommendations  are  based  on  the  technical  judgement  of  the  authors. 

Due  to  the  changing  nature  of  the  systems  features  and  the  user 
application  environment,  the  information  presented  is  current  only  to 
January  1986. 

DISTRIBUTION 

This  document  has  been  prepared  for  the  use  of  the  Nuclear  Regulatory 
Commission.  Responsibility  for  its  further  use  rests  with  that  agency. 
NBS  requests  that  if  release  to  the  public  is  contemplated,  such  action 
be  taken  only  after  consultation  with  the  Technical  Information  and 
Publications  Division  at  the  National  Bureau  of  Standards. 


SUMMARY 


The  establishment  of  a computer-assisted  database  has  been  initiated, 
and  is  suggested  for  further  development  and  full  implementation  for 
storage  and  retrieval  of  reviews  and  evaluations  of  high  level  waste 
(HLW)  data,  composed  principally  of  pertinent  waste-package  reports 
generated  by  DOE.  Initial  suggestions  by  materials  scientists  at  the 
NBS  on  the  type  and  form  of  information  to  be  stored  in  the  database 
were  reviewed  by  NBS  computer  scientists,  who  have  concluded  that  of 
the  available  software  of  packages,  Revelation  has  been  determined  to 
be  an  adequate  database  management  system  (DBMS)  for  this  application. 
Hardware  that  is  compatible  with  existing  NRC  equipment  is  recommended. 
The  format  for  storage  and  retrieval  of  information  using  Revelation 
will  require  further  development  for  full  implementation  of  this  DBMS 
for  use  with  the  reviews  of  reports  on  the  HLW  package. 

BACKGROUND 

In  support  of  the  technical  responsibilities  of  the  Department  of 
Energy  (DOE)  and  the  Nuclear  Regulatory  Commission  (NRC),  the  NBS 
has  undertaken  for  the  NRC  a task  of  conducting  reviews  and  evalua- 
tions of  DOE’S  technical  reports  on  high  level  waste  (HLW).  It  is 
expected  that  this  effort  will  be  an  ongoing  effort  that  will  involve 
the  evaluation  of  data  on  materials  performance  and  properties,  and 
that  it  will  result  in  a substantial  body  of  data  that  must  be 
gathered  and  stored  in  a manner  that  will  permit  rapid  access  for 
efficient  retrieval.  As  part  of  this  task,  this  study  has  been 
conducted  to  assess  the  problems  and  costs  associated  with  effec- 
tively storing  this  data  as  a computer  retrievable  database.  An 
analysis  of  the  requirements  of  a database  for  this  application  was 
initiated  at  the  NBS  after  an  initial  exposure  to  selected  HLW  docu- 
ments. The  documents  included  two  memoranda  (references  1 and  2)  on 
the  "Data  Base  File  Structure"  and  "HLW  Data  Base  Requirements  Analysis." 

The  above  memoranda  were  reviewed  and  assessed  by  materials  scientists 
at  the  NBS,  with  the  intention  of  determining  whether  or  not  the  struc- 
ture for  the  database  files  and  the  requirements  analysis  for  a HLW 
database  proposed  in  the  memoranda  were  adequate  for  the  intended 
purposes.  The  conclusions  of  the  requirements  analysis  were  not 
endorsed  because  the  software  had  not  been  adequately  addressed.  The 
proposed  file  structure  was  not  endorsed  because  the  NBS  workers 
needed  more  familiarity  with  the  problem.  Further,  the  NBS  workers 
view  the  software  and  the  structure  of  the  files  as  a set  of  problems 
that  must  be  addressed  together  in  the  development  of  an  effective 
computer-assisted  database.  One  way  to  proceed  would  have  been  to  buy 
the  hardware  and  then  write  software  to  meet  the  needs  dictated  by  the 
hardware  and  the  structure  of  files  created  for  containing  the  infor- 
mation. This  approach  is  implied  in  the  memoranda  and  is  regarded  by 
NBS  workers  as  likely  to  be  both  inefficient  and  costly,  both  in  the 
initial  implementation  and  in  the  later  maintenance  of  the  system. 
Therefore,  it  would  have  been  recommended  only  if  existing  software 
could  not  be  found. 
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Constraints  established  by  the  sponsor  at  the  outset  of  this  work  are 
described  in  references  3 through  5.  Thus  the  recommendations  given 
here  for  hardware  and  software  are  based  on  these  constraints,  and 
only  a few  of  them  are  discussed  in  the  text  to  follow. 


PLANNING  A DATABASE 

The  establishment  of  a computer  database  for  the  HLW  application  is 
viewed  as  a continuous  process  that  involves  familiarization  with 
the  overall  problem  and  the  existing  information,  and  includes 
determinations  of  the  types  and  quantity  of  information  that  will  be 
stored  and  the  types  of  queries  that  will  be  conducted  on  the  stored 
information.  Together  with  the  form  of  reports  to  be  prepared  these 
establish  the  basic  requirements  of  the  database  system.  An  addi- 
tional consideration  is  what  modes  of  operation  are  anticipated, 
as  this  partially  governs  hardware  requirements.  Next,  the  available 
software  and  hardware  are  studied  and  selected  to  meet  the  require- 
ments. First,  the  software  is  chosen,  and  then  the  hardware  can  be 
specified.  It  is  understood  that  the  hardware  must  be  compatible 
with  existing  NRC  microcomputers.  Further,  both  flexibility  and 
speed  of  the  database  system  must  be  adequate  for  various  modes  of 
operation.  The  available  software  packages  must  be  evaluated  for 
their  capabilities  in  relation  to  the  above  requirements. 

It  is  the  NBS  judgment  that  development  of  software  (from  scratch) 
is  far  too  costly  both  for  initial  investment  costs  and  for  main- 
tenance through  the  first  two  or  more  years  of  usage.  Therefore, 
a commercially  marketed  database  management  system  (DBMS)  would  be 
our  first  choice,  provided  that  one  is  found  that  meets  the  require- 
ments for  this  application.  While  a commercial  DBMS  generally  can  be 
expected  to  require  computer  professionals  to  write  some  software  to 
adapt  it  initially  to  the  unique  needs  of  the  database  system,  the 
level  of  effort  is  minimized  by  the  judicious  selection  of  a DBMS  for 
a given  application.  Further,  changes  in  the  software  required  to 
maintain  the  database  system  are  much  less  demanding  when  a commercial 
DBMS  is  used,  and  this  maintenance  software  frequently  can  be  written 
by  personnel  with  lower  levels  of  computer  expertise. 

The  hardware  requirements  include  the  following:  (1)  The  hardware 

must  be  compatible  with  existing  NRC  equipment  and  (2)  Candidate 
software  must  be  capable  of  being  run  on  the  IBM  PC  (or  compatible) 
hardware . 


MODES  OF  OPERATION 

After  the  hardware  is  selected  and  the  software  is  structured  to 
meet  the  specific  needs  of  the  information,  the  data  are  entered, 
stored,  and  retrieved  to  complete  the  first  cycle  in  the  process  of 
building  a database.  In  this  first  cycle,  the  data  will  be  taken 
from  NBS  reviews  of  selected  HLW  documents.  The  initial  architecture 
of  this  database  will  be  that  required  by  these  first  reviews.  This 
initial  implementation  will  lead  to  further  understanding  of  the 
requirements,  and  this  will  result  in  changes  in  the  structure.  Fields 
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will  be  added,  deleted,  and  changed  in  name,  size,  or  type.  Decisions 
for  major  restructuring  of  the  database  may  even  be  in  order,  during 
the  first  few  cycles.  Thus,  the  software  will  continue  to  be  modified 
until  its  form  has  been  tailored  to  meet  all  of  the  user  needs,  which 
themselves  probably  will  not  be  well  understood  until  the  system  has 
been  in  operation  for  sometime. 

Each  NBS  review  of  a document  will  be  actually  stored  in  one  or 
more  files,  but  for  simplicity  in  this  discussion,  a file  will  be 
regarded  as  containing  all  stored  information  for  one  document. 

Two  types  of  work  on  these  files  are  development  and  production. 

In  the  development  work,  the  structure  of  the  database  is  altered. 

In  the  production  work,  the  files  of  the  DBMS  are  altered  only  by 
the  data  clerk  responsible  for  updating  the  DBMS. 

Reviewers  will  create  the  reviews  that  are  modified  by  others  and 
entered  by  a data  clerk.  The  reviewer  uses  either  of  two  media. 

One  is  a handwritten  form  that  is  entered  into  the  DBMS  by  the  data 
clerk  after  it  is  in  final  form.  The  other  is  a computer  on  which  the 
reviewer  can  generate  a file  that  is  later  merged  into  the  DBMS  by 
the  data  clerk.  The  computer  may  be  one  of  the  two  PCs  recommended 
for  use  at  the  NBS  in  a HLW  Data  Center,  or  it  may  be  a portable 
unit  that  may  be  used  by  a reviewer  in  an  office,  at  home,  or  in 
another  library  as  needed.  While  the  make  and  model  of  the  computer 
best  suited  for  this  activity  has  not  been  established,  it  is 
intended  that  it  should  be  a PC  compatible  unit  that  is  highly 
portable.  In  the  process  of  creating  a review,  the  reviewer  may 
require  numerous  searches  of  the  database  to  answer  questions 
pertinent  to  the  review  in  question.  Thus,  another  feature  of  a 
portable  PC  compatible  computer  is  that  it  be  capable  of  storing 
the  files  that  contain  the  answers  to  the  reviewers’  queries.  The 
360Kb  floppy  diskette  is  the  media  of  choice  for  this. 

The  files  would  be  structured  and  restructured  by  the  manager  of  the 
database  or  by  a programmer  skilled  in  information  system  management. 
The  files  are  structured  to  facilitate  information  retrieval,  as 
reports.  Reports  are  prepared  in  an  agreed  upon  format,  with  a 
report  generally  being  a subset  of  the  data  contained  in  the  DBMS, 
and  with  the  format  being  one  suitable  for  use  by  the  NRC  and  its 
contractors.  The  stored  information  must  be  queried  to  satisfy  a 
user’s  request  for  information.  Normally,  this  query  will  yield 
answers  for  use  in  decisions  made  by  the  users:  NRC  workers,  NBS 

reviewers,  and  other  NRC  contractors. 

Index  information  will  be  stored  in  various  fields  that  are  accessed 
by  user  options,  in  the  normal  query.  The  text  fields  will  be 
available  for  "manual"  queries,  which  may  be  conducted  by  any  user 
of  the  database  system.  The  DBMS  must  support  large  text  fields  in 
a way  that  permits  an  optional  search  of  the  text.  If  minicomputers 
were  used,  their  speed  and  capacity  would  likely  permit  relatively 
rapid  searches  of  the  text  contained  in  the  database. 

After  the  appropriate  documents  have  been  identified  by  a query,  the 
query  furnishes  a list  of  applicable  documents.  The  user  may  opt  to 
read  the  full  review  of  each  document  or  to  use  the  review  along  with 
the  detailed  data  contained  in  the  original  full  document. 
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DATA  STRUCTURE 


The  preliminary  conclusion  is  that  the  HLW  database  should  contain 
five  logical  entities  of  information,  on  each  review  of  a document. 
One  will  be  an  index  used  for  making  quick  queries  of  the  contents  of 
the  document;  the  second  will  contain  bibliographic  information;  the 
third  will  contain  the  reviewer’s  assessment  of  the  contents  of  the 
document;  the  fourth  will  contain  the  reviewer's  evaluation;  and  the 
fifth  will  contain  textual  information  from  other  sources,  such  as  an 
abstract  or  an  executive  summary.  Searches  conducted  on  any  except 
the  first  of  these  entities  can  be  expected  to  be  slow,  in  general, 
especially  on  a microcomputer. 

One  important  conclusion  is  that  within  these  entities  a search 
will  have  to  be  conducted  on  any  of  four  types  of  fields: 

One-string  fields,  repeating  fields,  numeric  fields,  and  text-like 
fields.  While  some  index  data  can  be  stored  in  fields  containing 
only  one  string,  numerous  other  fields  within  the  five  entities 
will  contain  a number  of  words,  perhaps  more  than  200. 

Examples  of  one-string  fields  include  the  Identification  Number  of 
the  document  (e.g.,  CAT001 .DOE,  or  CAT03M.MCC),  Portion  of  the 
Waste  Package  (e.g.,  canister,  or  waste  form),  and  Temperature 
(e.g.,  25C,  or  100C).  This  last  item  typifies  a category  that 
presents  a special  problem.  There  may  have  been  measurements  taken 
at  numerous  temperatures  and  this  would  require  a different  storage 
and  searching  system  than  that  which  is  used  for  one  word,  or  one 
string  like  "waste  form." 

Examples  of  repeating  fields,  those  that  have  multiple  entries, 
follow: 

Material  (e.g.,  alloy  steel,  1020  C-Mn  steel,  or  any  of  a 
number  of  ferrous  and  non-ferrous  materials  that  were  tested); 

Authors  (e.g.,  Brown,  A.  W.,  Avery,  R.  R.,  Spike,  G.  T.) 

Environment  (e.g.,  brine,  groundwater,  and  NACE  standard  H2 
solution) 

For  fields  like  those  for  Material,  Authors,  and  Environment,  the 
examples  indicate  that  numerous  multiple  entries,  may  be  required. 
These  are  examples  of  fields  with  repeating  groups,  i.e.,  the  field 
may  be  repeated  an  indefinite  number  of  times. 

For  a field  like  the  Title  of  the  Document,  the  information  is 
similar  in  structure  to  that  which  would  be  given  in  a text  (or 
comment)  field.  To  search  these  types  of  fields  requires 
"substring"  search  capabilities.  A substring  can  be  nearly 
anything,  including  one  of  the  items  listed  in  a repeating  group. 
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Thus,  for  the  types  of  data  expected  in  an  HLW  database,  fields  may 
be  one-string,  repeating  groups,  numeric,  or  text.  The  DBMS  must 
be  able  to  conduct  the  query  for  each  of  these  types  of  fields,  so 
as  to  facilitate  data  entry,  retrieval,  and  reporting.  The 
expectation  is  that  reports  generated  by  the  DBMS  will  require  a 
format  that  differs  significantly  from  that  of  the  data  entries. 

One  concern  of  NBS  computer  scientists  who  reviewed  the  require- 
ments as  set  forth  by  the  materials  scientists  is  that  DBMSs 
designed  for  microcomputer  applications  usually  are  designed  to 
handle  only  the  "one-string"  type  of  data  entry,  and  this  would 
have  proven  to  be  very  inefficient  for  the  HLW  database  application. 

Detailed  numerical  tables  of  data  are  believed  to  be  unwarranted  in 
the  database  itself.  Other  numerical  data,  such  as  temperature  of 
test,  temperature  range  over  which  the  data  may  be  applicable, 
pressure,  various  mechanical  and  physical  properties  of  the 
material  tested,  etc.,  would  be  included  in  the  index.  Almost  all 
of  the  index  fields  would  not  be  numeric  entries.  These  would 
include:  Title,  keywords,  materials,  environmental  and  other  test 

conditions . 

LIMITATIONS  OF  MICROCOMPUTERS 

The  NRC  requires  that  the  proposed  HLW  database  should  be  compatible 
with  their  existing  microcomputers.  This  requirement  excludes  from 
consideration  existing  software  developed  for  minicomputers,  as  a 
portability  problem  would  be  associated  with  the  mixing  of  mini-  and 
microcomputers,  and  this  problem  would  be  costly  to  overcome.  While 
this  portability  problem  is  not  insurmountable,  we  regard  the  use  of 
minicomputers  for  this  application  to  be  ill  advised,  provided  that 
suitable  software  can  be  obtained  for  microcomputers.  More  importantly, 
in  this  application,  a principal  benefit  of  suitable  commerically 
available  software  for  microcomputers  is  related  to  portability  of  the 
entire  database,  the  structure  of  the  files  and  the  data.  On  the  other 
hand,  with  the  minicomputer,  portability  problems  could  be  very  costly 
to  solve. 

In  general,  the  software  developed  for  microcomputers  is  preferred 
for  this  application,  at  least  in  the  sense  that  it  is  often  more 
user  friendly  than  that  developed  for  either  the  minicomputer  or 
the  mainframe  computer.  User  friendliness  translates  into  lower 
costs  for  initially  establishing  and  for  later  maintaining  the 
database  system,  with  the  software  costs  being  kept  to  a minimum  if 
the  microcomputer  can  be  used  to  do  all  or  most  of  the  storing  and 
processing  of  the  data. 


DBMS  SOFTWARE  for  the  PC 

The  database  management  systems  (DBMSs)  developed  for  microcomputers 
have  been  predominately  modeled  after  the  relational  database.  Tradi- 
tionally, the  DBMS  developed  for  the  microcomputer  has  been  designed 
to  handle  the  one-string  and  numeric  types  of  data  entries,  e.g., 
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dBase  III.  However,  some  of  the  more  advanced  systems,  such  as  Revela- 
tion, can  also  be  used  for  the  two  other  types  of  fields  described 
above  (repeating,  variable  length). 

Software  for  use  on  minicomputers  and  mainframe  computers  have  tradi- 
tionally been  developed  to  process  information  stored  in  "hierarchical" 
and  "network"  structures.  The  structure  of  either  the  hierarchical  or 
the  network  database  has  the  following  characteristics:  (1)  It  permits 
very  fast  searches,  (2)  it  is  relatively  difficult  to  update  while 
maintaining  the  integrity  of  the  file,  and  (3)  it  requires  a high 
level  of  skill  to  generate  reports.  Thus,  the  design  of  the  database 
is  determined  by  knowledge  of  how  the  database  is  to  be  used;  and 
software,  for  large  computers  have  better  features,  especially  speed 
and  the  capabilities  to  handle  various  types  of  fields.  For  this 
application  the  disadvantages  of  mini-  and  mainframe  computers  are 
the  costs  of  the  software  and  its  maintenance.  In  addition,  both  the 
initial  and  the  maintenance  costs  for  the  hardware  are  generally  higher 
than  for  microcomputers. 

With  the  relational  approach,  the  data  are  stored  as  tables  that 
include  a unique  identifier  for  each  row  of  the  table.  For  example, 
each  reviewed  document  will  have  a unique  designation  that  is  carried 
along  in  each  of  the  files  on  that  document.  These  identifiers  faci- 
litate the  search  process.  The  architecture  of  the  files  within  the 
DBMS  must  be  designed  to  access  those  data  in  a manner  consistent 
with  the  intended  usage.  The  best  known  relational  software  packages 
were  written  for  microcomputers. 


The  Fixed-Field  DBMS 

In  this  type  of  DBMS,  the  amount  of  space  required  for  storage  equals 
the  amount  of  space  that  is  searched.  Data  are  stored  in  fields  that 
have  their  length  fixed  at  a value  corresponding  to  the  maximum  size 
that  may  be  required  for  any  single  entry  made  in  that  particular 
field.  For  some  fields,  this  can  be  a large  field  size,  and  it  can 
contrast  sharply  with  the  mean  length  of  an  entry  for  the  particular 
field,  i.e.  it  may  be  much  larger  than  the  actual  amount  of  informa- 
tion that  is  usually  stored  in  that  field.  Because  this  anticipated 
length  must  be  searched  every  time  the  field  is  searched,  both  the 
search  time  and  the  storage  capacities  are  affected  adversely  when 
the  fixed-field  DBMS  is  used. 

In  most  current  DBMSs,  including  dBASE  III  which  is  the  only  DBMS 
listed  (Ref.1)  in  the  NRC  Standard  PC  Software,  the  data  are  divided 
into  fields  (columns)  of  predetermined  size.  The  largest  field  that 
dBASE  III  can  hold  is  4000  bytes,  which  is  about  one  full  page  of  text. 
A change  in  the  size  or  position  of  a fixed-sized  field  requires  an 
extensive  knowledge  of  the  DBMS  and  is  not  done  lightly.  It  requires 
the  supervision  of  the  database  manager,  and  the  problems  that  might 
be  encountered  include  (1)  previously  stored  information  may  be  lost, 
(2)  available  storage  space  may  be  exceeded,  (3)  forms  for  output 
must  be  altered  to  describe  the  new  form  of  the  database,  etc.  There 
are  other  problems  with  the  use  of  fixed  fields,  as  described  below. 
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The  imposition  of  limits  on  the  size  of  the  fields  for  either  the 
keyword  or  comment  fields  would  place  unwanted  constraints  on  the 
editors  and  it  would  complicate  data  entry. 

When  a predetermined  space  has  been  reserved  for  fields  that  normally 
would  contain  various  lengths  of  information,  such  as  for  keywords, 
authors,  or  comments,  a good  part  of  the  field  will  normally  contain 
blanks,  which  are  the  spaces  needed  for  the  largest  known  entry.  The 
presence  of  these  blanks  uses  both  RAM  and  disk  space.  Further,  in 
the  fixed-field  system,  when  a data  entry  is  larger  than  the  reserved 
space  for  that  field,  one  is  very  tempted  to  truncate,  abbreviate,  or 
omit  information  instead  of  restructuring  the  DBMS.  Thus,  the  choices 
made  by  the  builder  are  compromises  that  consider  the  available  memory, 
the  database  requirements,  and  restructuring. 

Thus,  a fixed  field  size  in  a DBMS  lends  itself  to  very  fast 
mathematical  search  schemes,  but  it  complicates  both  the  structure 
of -the  search  language  and  the  formats  for  generating  of  reports. 


The  Variable-Length  Field  DBMS 

Some  DBMSs  have  a free  form,  that  is  the  lengths  of  the  fields  are 
variable  and  dependent  only  on  the  amount  of  information  stored  in 
the  field.  Thus,  information  is  packed  into  this  type  of  DBMS  and 
there  are  no  empty  spaces  in  fixed-field  DBMSs.  Four  commonly  used 
free-form  DBMSs  are  Dayflo,  Oracle,  Revelation,  and  Sci-mate. 

Revelation  will  be  used  as  our  prime  example  in  the  discussion  to 
follow. 

When  compared  with  the  above  fixed-field  types  of  DBMS,  systems 
developed  for  fields  of  data  containing  strings  of  information  of 
indeterminate  length  follow  a different  logic  of  storage.  Examples 
of  the  latter,  which  is  sometimes  called  free  form,  are  the  commer- 
cially available  Revelation  and  ABCUP,  developed  at  NBS  on  an  HP-1000 
mini  computer. 

Instead  of  a table  of  fixed  size,  the  information  is  stored  as  books 
would  be  on  library  shelves.  An  entry  is  stored  in  its  entirety  and 
an  empty  entry  takes  up  no  space.  Therefore,  in  these  systems,  no 
space  is  wasted  on  null  information  and  the  entire  RAM  and  disk  are 
utilized  for  meaningful  data.  Data  restructuring  is  normally  accom- 
plished simply  by  adding  new  fields  when  desired.  These  fields  are 
not  limited  in  size  or  by  any  characteristics,  except  by  the  intended 
limitation  dictated  by  the  type  of  data  to  be  stored. 

When  compared  with  numbers,  strings  of  characters  are  more  difficult 
to  input  and  proofread.  Therefore,  for  string  data,  computer  assis- 
tance is  needed  to  keep  strict  control  on  the  contents  of  a field. 
Revelation  can  be  instructed  to  (1)  parse  (check  at  the  time  of  data 
entry)  for  specific  "allowed"  values  within  specified  fields;  (2)  insert 
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default  values,  (3)  match  the  input  against  a predetermined  set  of 
acceptable  strings.  Further  it  allows  development  of  BASIC  code  to 
mathematically  manipulate  data.  For  example,  a code  could  be  written 
to  check  validity  of  input  or  to  take  a unit  [degrees  F],  convert  it 
to  another  unit  [degrees  K],  and  store  the  conversion  in  a field  used 
for  searches.  These  examples  of  the  advantages  of  some  of  the  nonfixed- 
field  DBMSs,  provide  for  operations  that  are  very  difficult  or 
impossible  using  a fixed-field  DBMS,  such  as  dBASE  III. 

Although  the  internal  structure  of  Revelation  makes  it  inherently 
slower  for  searches  when  compared  with  dBASE  III,  the  difference 
in  search  speed  could  be  minimized  by  thoughtful  design  of  the  fields 
and  files  making  up  the  HLW  database. 

An  indepth  comparison  of  dBASE  III  vs  Revelation  appears  in  reference  6. 


SIZE  OF  THE  PROPOSED  DATABASE 

Each  review  of  a report  will  be  stored  in  a separate  record. 

It  is  estimated  that  each  record  would  contain  no  more  than  about  5 
packed  pages  or  about  25,000  characters.  It  is  anticipated  that 
about  1000  records  will  be  stored  over  a period  of  about  5 years. 
This  could  generate  as  much  as  25  Megabytes  of  data.  This  database 
size  assumes  that  the  variable-length-field  concept  will  be  used  to 
store  the  data.  If  fixed-field  DBMSs  were  to  be  used  for  this  same 
task,  a much  greater  memory  storage  capacity  would  be  required. 


ESTIMATES  ON  NBS  USAGE 

The  database  would  involve  activities  of  about  a dozen  workers:  A 
database  manager,  a data  clerk,  and  about  10  reviewers.  The  time 
that  each  worker  will  devote  to  interaction  with  the  database  is 
actually  indeterminate  and  it  is  a strong  function  of  time  over  the 
next  five  year  period.  Nevertheless,  estimates  for  the  immediate 
future  are  given  below  for  NBS  users  only: 


In  addition  to  these  NBS  users,  there  are  others  who  would  use  the 
data.  Only  NBS  workers  will  alter  the  files.  These  will  be  the 
systems  analyst  who  restructures  the  database  and  the  database  manager 
and  clerk  who  enter  data.  Those  who  would  only  access  the  files 
include  NBS  users  (reviewers,  database  manager  and  program  manager), 
NRC  Workers,  NRC  Contractors,  and  other  users. 

File  alterations  (development  and  production)  would  be  conducted  on  a 
PC  designated  as  a "server".  This  unit  would  have  an  internal  hard 
disk  for  primary  storage  and  an  external  storage  media  would  back  up 
these  data  files.  A second  PC,  designated  as  a user  unit,  would  serve 


time  in  hours  per  week 


Development  work  by  System  Analyst — 
Production  work  by  Data  Clerk — 
Reviewers — 


0 to  30,  ave.  15 
20  to  40,  ave.  25 
1 0 to  50,  ave . 25 


8 


the  needs  of  reviewers  primarily.  Although  this  second  unit  is  indepen- 
dant of  the  server,  it  could  be  and  would  be  used,  as  needed,  for  the 
development  and  production  operations.  For  example,  the  system  analyst 
could  work  at  it  even  while  production  work  is  being  done  by  the  data 
clerk. 

The  user  unit  will  normally  be  for  frequent  and  rapid  access  to  the 
information  in  the  files.  This  is  done  mainly  by  reviewers.  It  is 
anticipated  that  this  unit  will  be  set  up  in  a multiuser  mode,  so  that 
nearby  and  remote  PC’s,  one  of  which  already  exist  in  the  reviewer 
group,  can  be  used  to  access  these  files.  The  printer  for  the  second 
unit  will  serve  two  purposes  and  it  need  not  have  the  quality  of  the 
primary  printer  used  for  formal  reports.  This  unit  will  be  used  to 
obtain  quickly  paper  copies  for  users  and  to  assure  compatibility  with 
the  NRC  recommended  hardware. 

This  compatibility  issue  is  particularly  important.  It  must  be  assured 
that  printers,  on-  and  off-site,  will  print  the  identical  special  char- 
acters (and  super-  and  subscripts).  The  two  units  will  be  connected 
in  a mode  best  suited  for  rapid  communications.  This  is  to  facilitate 
transfer  of  data,  especially  that  from  the  server  to  the  user.  The 
reviewers’  file  must  be  constantly  kept  current.  After  the  system  has 
been  in  operation  and  procedures  have  been  developed  for  porting  to  a 
portable  unit  (discussed  earlier),  the  user  unit  would  be  used  by 
reviewers  to  create  subsets  of  the  database  for  use  in  the  portable 
unit  at  remote  locations. 


SOFTWARE  SELECTION 

A list  of  16  requirements  were  reviewed  in  the  process  of  selection 
and  these  are  given  in  Appendix  I titled  Software  Selection.  Software 
selection  was  based  in  part  on  the  above  considerations.  Candidate 
DBMSs  for  this  application  were  selected  by  screening  a large  list  of 
commercial  DBMSs  that  have  been  reviewed  in  "Project  Database"  which 
is  published  in  PC  Magazine.  The  issues  examined  are  dated  June  12 
and  24,  August  7 and  21,  and  September  4 and  18.  All  six  are  part  of 
Volume  3 (Ref.  6).  Features  and  restrictions  (such  as  limits  on 
record  sizes  and  numbers  of  fields)  for  each  listed  DBMS  were  reviewed 
in  relation  to  the  requirements  of  this  application.  Two  criterion 
used  in  reviewing  DBMSs  are:  1 . The  quantity  and  quality  of  searchable 
data  is  much  more  important  than  the  speed  of  search,  and  2.  the 
database  should  have  a free-form  structure  to  accomadate  a high  expected 
variance  in  field  length. 

Thus,  four  free-form  DBMSs  were  selected  for  further  review  to 
determine  if  any  of  them  satisfied  requirements  established  for  this 
application.  The  result  of  this  review  of  four  DBMSs  that  use 
variable-length  fields  is  the  recommendation  that  Revelation  is  the 
most  suitable  DBMS  for  this  application. 

Other  DBMS  candidates  considered  include  Dayflo,  Oracle,  and  Sci-mate. 
All  four  were  evaluated  in  terms  of  the  requirements  set  forth  in  the 
Appendix.  Revelation  is  currently  being  used  at  the  NBS,  on  a Compaq, 
in  the  Occupational  and  Health  Safety  Division. 
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Although  the  requirements  of  this  database  have  been  evaluated  by 
NBS , as  set  forth  in  this  document,  it  is  expected  that  they  will  be 
firmly  established  only  after  the  suggested  system  has  been  in  opera- 
tion for  some  time.  Some  of  these  requirements  are  based  on  the 
expected  modes  of  operation. 


HARDWARE  SELECTION 

One  of  the  principal  guidelines  set  forth  for  this  HLW  database  is 
that  the  system  must  be  compatible  with  the  IBM  PC,  IBM  PC-XT,  and 
Compaq  microcomputers,  which  are  currently  in  use  and  being  purchased 
by  the  NRC.  It  is  noted  that  while  minicomputers  are  more  powerful 
and  while  they  may  have  significant  advantages  for  this  application 
in  terms  of  available  software,  capacity,  and  speed,  the  problem  of 
interfacing  them  to  the  existing  NRC  microcomputers  could  prove  to 
be  costly.  Further,  the  initial  investment  in  minicomputers  would  be 
higher  as  well.  With  this  in  mind  the  discussion  that  follows  on 
microcomputers  was  prepared. 


Comparison  of  the  IBM  PC-AT  and  PC-XT 

The  IBM  PC-AT  and  IBM  PC-XT  are  prime  candidates  for  this  applica- 
tion because  of  their  compatibility  with  the  current  NRC  hardware. 

The  AT  has  the  potential  for  much  greater  speed  of  processing  and 
therefore  shorter  times  may  be  required  to  make  complex  queries  of 
the  database.  Revelation  has  been  written  to  take  advantage  of  the 
higher-speed  chip  that  is  resident  in  the  AT.  Further,  code  written 
for  the  XT  can  be  used  on  the  AT  at  a speed  at  least  equal  to  that 
obtained  with  the  XT,  as  the  AT  can  be  operated  using  the  disk 
operating  system  (DOS)  of  the  XT.  Speed  will  be  a most  important 
consideration  as  the  database  grows  and  the  number  of  records  is. 
increased  to  levels  that  require  significant  times  for  obtaining  an 
answer  to  a query. 

Basically,  the  AT  has  the  more  modern  architecture  developed  for 
the  PC  line  of  microcomputers;  an  investment  in  it  could  also  be 
warranted  on  this  basis,  as  new  developments  of  enhanced  capabilities 
are  much  more  likely  to  be  serving  the  AT. 


Recommendations 

Clearly,  either  an  AT,  or  an  XT,  or  a PC  with  an  attached  disk  drive 
(see  minimum  configuration  in  Appendix  I)  can  be  used  for  accessing 
the  database.  In  each  case,  the  information  would  be  developed  on  the 
same  operating  system  and  there  is  no  question  of  compatibility  or 
transferability.  Speed  is  the  principal  advantage  of  the  AT,  but 
other  considerations  mentioned  above  are  very  important  to  the  prac- 
tical usefulness  of  the  database  depending  on  the  frequency  of  usage 
and  the  types  of  queries  to  be  conducted.  The  initial  implementation 
of  this  work  has  been  completed  using  an  IBM  PC-AT. 
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Based  on  this  experience  and  a cost  analysis  that  is  presented  in  the 
Appendix  and  discussed  briefly  below,  it  is  recommended  that  two  PC-AT 
units  that  are  virtually  identical  should  be  purchased  for  this  work. 
The  usage  estimates  given  above  show  that  these  units  will  not  be  idle 
and  we  estimate  that  the  time  saved  by  using  the  AT,  which  has  a faster 
processor,  will  be  justified  in  productivity  gains  of  the  workers,  and 
other  justifications  are  cited  elsewhere  in  this  report.  The  cost 
difference  is  only  about  $1,M80  over  that  of  the  comparable  XT  system. 
There  is  no  advantage  to  making  one  of  these  units  different  from  the 
other;  in  fact,  there  are  a number  of  disadvantages  that  naturally 
arise  from  the  fact  that  a number  of  time-intensive  users  will  want  to 
use  either  machine  without  regard  to  questions  of  speed,  mode  of  opera- 
tion, or  keyboard  ergonomics. 

The  printers  for  the  two  units  are  different  for  reasons  discussed 
above,  one  is  for  formal  reports  and  the  other  is  for  users.  The 
portable  computer  discussed  above  has  not  been  selected,  and  it  is 
recommended  that  this  selection  be  made  after  the  system  has  been  in 
operation  and  time  is  available  to  determine  which  models  will  best 
serve  the  intended  functions  with  a minimum  in  software  development 
costs,  if  any. 

The  figures  quoted  below  for  the  high  usage  sites  include  costs  of  all 
anticipated  hardware  required  to  make  the  system  fully  operational  and 
they  include  the  cost  of  a Bernoulli  20+  external  storage  unit.  Two  of 
these  units  are  included  in  the  recommendations  given  below,  with  the 
intention  of  using  them  as  the  primary  transport  media  that  will  be 
used  for  keeping  the  files  at  the  NRC  current.  The  intention  is  to  use 
one  at  the  NBS  for  both  backup  and  transporting,  and  the  other  at  the 
NRC,  where  it  could  be  used  to  access  the  data  even  when  only  the 
minimum  recommended  system  is  available.  Transport  of  the  entire 
database  will  be  made  using  Bernoulli  disks.  Transport  of  occasional 
(low-volume)  communications  and  networking  operations  can  be  conducted 
using  a modem. 

It  is  understood  that  transportability  of  the  entire  database  within 
the  NRC  is  desired.  This  requirement  leads  to  the  recommendation  of 
the  20+  Bernoulli.  If  this  were  not  a requirement,  less  costly  alter- 
natives to  the  20+  Bernoulli  could  be  recommended.  The  20+  Bernoulli 
could  be  used  (at  NRC)  either  to  upload  the  entire  database  to  an 
internal  hard  disk  or  to  support  a PC  having  the  minimum  configuration. 

A document  reader  will  be  used  to  reduce  costs  of  data  entry  from  non- 
PC  sources.  By  judicious  selection  of  a multiplicity  of  fonts  the 
reader  will  permit  rapid  entry  of  abstracts,  etc.  directly  from  tech- 
nical articles,  and  from  any  review  forms  that  are  not  prepared  on  a PC. 


COST  ESTIMATES 

Under  Hardware  Recommendations  in  Appendix  I,  costs  are  given  for  the 
recommended  PC  hardware  that  has  been  determined  to  be  suitable  for  use 
with  Revelation  in  this  application.  Three  systems  are  priced.  One  is 
the  cost  of  the  AT  systems  recommended  for  high  usage  sites,  with  the 
Quietwriter  printer  ($10,699)  and  with  an  Epson  printer  ($10,102).  The 
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second  is  an  XT  system  recommended  for  low-usage  sites  ($8622),  and  the 
third  is  a minimum  recommendation  configuration  for  low-usage  sites  ($3676)  . 

If  the  first  two  are  compared  using  the  same  printer,  the  difference  in 
cost  between  an  AT  and  an  XT  configuration  can  be  obtained,  and  this 
value  is  $1480.  It  is  given  here  as  a reference  for  use  in  the  recom- 
mendations given  above. 

A summary  of  the  estimated  costs  for  the  hardware  for  the  proposed 
computer  assisted  databsase  for  reviews  and  evaluations  on  high-level 
waste  data  is  given  in  Table  1 . The  estimated  costs  of  the  recommended 
vender  supplied  software  are  given  in  Table  2.  The  tables  indicate 
that  hardware  will  cost  $39,929  and  the  software  $2005,  for  a total  of 
approximately  $42,000.  It  is  expected  that  the  additional  cost 
required  to  fully  develop  and  operate  the  database  will  be  about 
$50,000  per  year  greater  than  the  cost  required  to  present  the  reviews 
in  hard  copy  form  only,  i.e.  with  no  database  storage  or  retrieval  of 
the  reviews.  This  cost  will  diminish  by  about  a factor  of  two  after 
the  first  two  or  three  years  of  operation,  as  they  would  include  mainly 
the  solution  to  software  and  hardware  problems. 


IMPLEMENTATION  OF  REVELATION  FOR  A HLW  DATABASE 

The  proposed  database  has  been  implemented  for  the  bibliographic  parts 
of  the  information,  using  the  DBMS  Revelation.  A list  of  data  elements 
for  the  bibliographic  file  and  their  descriptions  are  given  in 
Appendix  IIC.  In  addition,  the  file  structure  for  the  entire  database 
has  been  designed.  Guide  forms  have  been  created  to  assist  reviewers, 
to  minimize  ambiguity  in  the  instructions,  and  to  facilitate  the  estab- 
lishment of  a system  for  development  of  keyword  lists  (see  Appendix  IIA 
and  IIB).  The  keyword  lists  will  be  useful  in  conducting  a limited  but 
rapid  search  of  extensive  data  files  in  the  proposed  database.  The 
various  forms  developed  for  use  with  this  database,  include  the  com- 
pleted review  forms  (Appendix  IID),  and  an  output  of  the  bibliographic 
file  (Appendix  HE).  This  output  is  in  raw  form  intended  only  to 
demonstrate  the  status  of  the  work  and  is  not  intended  as  the  final 
form  for  reporting. 

Using  Revelation,  a user  may  search  for  any  alphanumeric  character 
string,  in  any  field  regardless  of  the  size  of  the  field.  Thus, 
Abstract,  General  Comment,  Type  of  Data,  fields,  etc.,  can  be 
searched  for  information  not  in  the  keyword  lists. 
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Table  1 


Summary  of  Costs  of  Recommended  Hardware 


PC-AT  Table  1 , the  Appendix  configuration 

1 each  with  IBM  Quietwriter  printer  $10,699. 

1 each  with  Epsom  XF-85  printer  10,102. 

Document  reader  (estimate)  13s500. 

Portable  computer  (estimate)  4,500. 

Six  each  extra  Bernoulli  cartridges  398. 

100  each  floppy  disks  - 360  Kb  200. 

1.2  Mb  530. 

Total  $39,929. 

Table  2 

Summary  of  Costs  for  Vendor  Supplied  Items 

Software  from  Revelation  - Estimated  Software  Costs 

Version  G.2  of  Revelation  (for  server)  $ 950. 

Runtime  (for  use  at  NRC)  200. 

Runtime  (for  use  at  NBS)  200. 

Network  Revelation  (optional) 

Bump  disk  for  4 users  at  NBS  495 . 

Subtotal  $ 1,845. 

Operating  System  from  IBM 

DOS  3.1  (2  each)  $ 160. 

Total  $ 2,005. 
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REQUIREMENT  ANALYSIS 


The  selected  database  management  system  for  the  NRC 
database  must  run  on  an  IBM  PC  or  compatible,  and  it  must 
support : 


o variable  length  fields, 
o field  lengths  of  7000  characters, 
o record  lengths  of  22,047  characters, 
o a minimum  of  44  fields, 
o repeating  fields, 
o multiple  large  text  fields, 
o indexing, 

o searching  large  text  fields, 
o report  generating, 
o data  dumping, 
o bulk  loading, 
o integrity  checking, 
o structure  modification, 
o a minimum  of  1000  records, 
o menu  building,  and 
o programming. 


The  numbers  in  the  above  features  are  based  on  an  initial 
set  of  data  elements  that  are  proposed  for  calculation  pur- 
poses only.  See  the  appendix  for  a listing. 

Variable  Length  Fields . Assignment  of  variable  length 
fields  is  essential  for  the  conservation  of  storage  space, 
which  is  at  a premium  on  microcomputers.  Variable  length 
storage  is  required  both  for  fields  with  specified  upper 
limits  and  for  those  without.  That  is,  string  values  that 
are  assigned  to  fixed  length  field  types  should  not  be  pad- 
ded with  spaces  up  to  the  maximum  allowed  character  length. 

Field  Lengths  of  7000  Characters . Each  record  in  the 
NRC  database  will  contain  the  "review  and  evaluation"  infor- 
mation for  a particular  document.  For  this  reason,  an  as- 
signed field  value  may  contain  as  much  as  one-half  to  one 
and  one-half  pages  of  text.  Examples  are  the  assignment  of 
abstract  or  comment  fields. 

Record  Lengths  of  22,047  Characters . The  sum  of  the 
maximum  possible  field  lengths  in  the  initial  record  struc- 
ture for  the  NRC  database  total  22,047  characters.  This 


16 


% 


number  of  characters  is  the  minimum  requirement  of  any 
selected  data  management  software. 

A Minimum  of  44  Fields . The  proposed  structure  for  the 
NRC  database  identifies  44  fields.  Thus,  any  selected  data 
management  software  must  allow  defining  a minimum  of  44 
f ields . 

Repeating  Fields . Some  fields  for  a given  record  oc- 
currence (in  the  NRC  database)  will  have  more  than  one  as- 
signable value.  These  are  repeating  group  fields  which  will 
require  a special  definition  language.  The  language  must  be 
able  to  handle  a variable  number  of  assignable  values  to  a 
given  field. 

Multiple  Large  Text  Fields . The  initial  structure  for 
the  proposed  NRC  database  specifies  that  several  large  text 
fields  may  be  included  in  the  record  for  any  given  document. 
Both  the  abstract  and  several  different  comments  about  a do- 
cument will  be  assigned  as  separate  fields. 

Indexing . To  speed  up  searching,  a data  management 
package  will  be  required  to  have  an  indexing  capability. 
This  capability  will  prove  to  be  increasingly  beneficial  as 
the  database  grows,  because  search  time  increases  greatly 
with  the  number  of  records  searched. 

Searching  Large  Text  Fields . There  are  also  those 
cases  when  a search  constraint  may  specify  a field  that  is 
not  indexed  or  that  is  not  a key.  This  wil-l  be  true  during 
the  early  developments  of  the  NRC  database  because  comments 
and  abstracts  may  include  candidate  keywords  that  were  not 
evident  initially.  Searching  record  occurrences  in  either 
the  abstract  or  comment  fields  will  require  the  selected  da- 
tabase management  system  to  possess  a powerful  substring 
searching  capability. 

Report  Generating . Reproduction  of  reviews  and  evalua- 
tions will  be  necessary,  and  in  some  cases,  special  reports 
will  be  generated.  The  report  generator  may  require  an  in- 
terface with  the  database  through  a high-level  programming 
language.  Thus,  the  selected  database  management  system 
should  allow  interfacing  through  a high-level  programming 
language . 

Data  Dumping . The  operations  of  a database  at  user 
sites  will  require  periodic  updates  from  the  central  office 
and  perhaps  comments  to  the  central  office.  This  transfer 
will  require  the  selected  database  management  system  to  pos- 
sess both  an  import  and  export  facility  that  can  handle  the 
necessary  data  transfers  between  locations. 
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Bulk  Loading . The  initial  population  of  the  NRC  data- 
base will  require  extensive  typing  by  clerical  personnel  un- 
less the  selected  database  management  system  can  adequately 
handle  bulk  loading  of  any  existing  data.  The  database 
management  system  should  possess  a loading  facility  that  can 
accept  a plain  ASCII  file  with  clearly  specified  field 
separators . 

Integrity  Checking . Upon  entering  data,  the  data 
management  software  must  support  the  option  to:  (1)  test  the 
format  of  the  entered  data,  and  (2)  test  the  entered  data 
against  a specified  set  of  values.  Such  options  will  ensure 
the  integrity  of  critical  data. 

Structure  Modification.  The  structure  of  the  fields 
for  the  proposed  NRC  database  is  expected  to  change  periodi- 
cally in  the  initial  development  stages.  Thus,  the  selected 
data  management  package  should  allow  structural  modifica- 
tions with  a minimum  amount  of  difficulty. 

A Minimum  of  1000  Records . It  is  projected  that  the 
proposed  NRC  database  will  contain  record  information  on  at 
least  1000  documents  over  a period  of  about  5 or  so  years. 
Storing  1000  records  is  not  a limitation  for  most  data 
management  software;  however,  limitation  comes  into  play 
when  those  records  may  contain  as  many  as  22,047  characters. 

Menu  Building . As  mentioned  previously,  clerical  help 
may  be  required  to  enter  the  data  for  record  occurrences. 
This  will  require  a system  that  is  both  simple  and  easy  to 
use.  However,  the  selected  database  management  system  should 
lend  itself  both  to  the  development  of  menus  and  to  the 
flexibility  or  ease  of  alterating  existing  menus.  Such  a 
menu  building  capability  will  allow  tailoring  the  capabili- 
ties of  the  system's  data  manager  to  a specific  application. 

Programming . In  some  cases,  it  will  be  necessary  to 
augment  the  capabilities  of  the  system's  data  manager  with 
those  of  a programming  language.  A programming  language 
will  allow  the  development  of  controls  for  the 
user/interface  procedures  that  cannot  be  readily  achieved 
otherwise . 
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EVALUATION  PROCESS 


The  evaluation  process  to  select  a database  manage- 
ment system  for  the  NRC  database  involves  two  phases.  In 
phase  one,  we  reviewed  the  manuals  of  each  candidate  DBMS. 
The  reviews  entailed  analyzing  the  features  of  a DBMS  pack- 
age using  the  criteria  discussed  in  the  requirement  analysis 
section.  If  analysis  revealed  the  absence  of  any  features 
that  are  critical  to  the  development  of  the  proposed  NRC  da- 
tabase, the  DBMS  was  dropped  as  a candidate  and  no  further 
consideration  was  given  to  it. 

In  the  second  phase  of  our  evaluation  process,  we  will 
implement  a version  of  the  NRC  database  file  structure  and 
perform  testing  on  a subset  of  the  records  that  will  popu- 
late the  database.  The  structure  of  the  database  will  vary 
from  one  DBMS  package  to  the  other.  This  fact  will  be  noted 
in  any  performance  testing.  The  variation  is  required  be- 
cause the  database  must  be  structured  to  the  form  required 
by  the  structure  of  the  database  management  system. 


EVALUATION  RESULTS 


Each  of  four  software  packages  considered  is  capa- 
ble of  running  on  hardware  that  is  compatible  with  the  IBM 
PC  family.  The  software  under  consideration  include  DayFlo, 
ORACLE,  Revelation,  and  Sci-mate.  Evaluating  the  features  of 
each  software  package  resulted  in  the  table  on  the  following 
page . 


DAYFLO 


Variable  Length  Fields . Specification  of  field 
lengths  is  not  required.  Fields  are  limited  only  by  the  max- 
imum record  length. 

Maximum  Field  Leng th . A field  may  contain  a maximum  of 
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— ->>_^_Softworc 
Feature  ~~ 

Dayflo 

Oracle 

Revelation 

Sci-mate 

Variable  Length  Field 

yes 

yes 

yes 

yes 

Field  Length  of  7000 
Characters 

yes 

yes 

yes 

no 

Record  Lengths  of 
22,047  Characters 

yes 

yes 

yes 

no 

A Minimum  of  44 
Fields 

yes 

yes 

yes 

no 

Repeating  Fields 

yes 

no 

yes 

no 

Multiple  Large 
Text  Fields 

yes 

no 

yes 

no 

Indexing 

yes 

yes 

yes 

no 

Searching  Large 
Text  Fields 

yes 

no 

yes 

no 

Report  Generating 

yes 

yes 

yes 

yes 

Data  Dumping 

yes 

yes 

yes 

no 

Bulk  Loading 

yes 

yes 

yes 

yes 

Integrity  Checking 

yes 

yes 

yes 

no 

Structure  Modifi- 
cation 

yes 

yes 

yes 

yes 

A minimum  of  1000 
Records 

yes 

yes 

yes 

yes 

Menu  Building 

no 

yes 

yes 

no 

Programming 

no 

yes 

yes 

no 
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32,000  characters.  This  is  well  over  the  required  7000  char- 
acters for  the  NRC  database. 

Maximum  Record  Length . Records  may  contain  up  to 
32,000  characters.  This  length  satisfies  the  22,046  charac- 
ters requirement  for  a record  in  the  NRC  database. 

Maximum  Number  of  Fields . The  maximum  number  of  fields 
is  limited  only  by  the  32,000  characters  that  are  allowed 
per  record. 

Repeating  Fields . Multivalued  fields  are  allowed.  How- 
ever, there  is  no  way  to  group  repeating  values  across  dif- 
ferent repeating  fields. 

Multiple  Large  Text  Fields . The  number  of  large  text 
fields  is  limited  only  by  the  maximum  number  of  characters 
per  record. 

Indexing . Indexing  is  maintained  through  field  names.  A 
maximum  of  32  indexes  is  allowed  per  record. 

Searching  Large  Text  Fields . Searching  may  be  per- 
formed on  text  fields  of  any  size  (e.g.  7000  characters) 
through  substring  searching  capabilities.  However,  large 
text  fields  can  not  fully  utilize  the  indexing  capabilities; 
therefore,  searches  will  be  performed  sequentially  and  much 
more  slowly  than  on  a fully  indexed  field. 

Report  Generating . Document  formats  can  be  specified 
easily.  These  specifications  identify  which  fields  are  to  be 
printed  and  their  page  locations.  However,  reports  are  lim- 
ited to  the  2,500  records  resident  in  the  work  space. 

Data  Dumping . Records  may  be  dumped  as  an  ASCII  file. 
Field  values  may  or  may  not  be  tagged  by  their  respective 
field  names. 

Bulk  Loading . Records  can  be  loaded  from  an  ASCII  file. 
However,  field  values  are  not  assigned  to  respective  fields. 
This  assignment  has  to  be  performed  by  the  operator. 

Integrity  Checking . Integrity  checking  is  performed 
through  pattern  matching.  A specified  pattern  controls  the 
string  values  that  can  be  assigned  to  fields.  If  a string 
value  does  not  match  the  specified  pattern,  it  is  not  store 
as  a field  value. 

Structure  Mod ification.  Structure  modifications  can  be 
made  easily.  Modifications  are  made  directly  to  the  diction- 
ary information  (i.e.,  field  size,  field  name,  field 
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addition  and  field  deletion).  The  modification  process  is 
completely  menu  driven. 

Maximum  Number  of  Records . A database  may  hold  up  to 
65,000  records  or  pages  of  information.  Of  this  number,  only 
2,500  are  available  at  any  time  for  a designed  worked  area. 

Menu  Building . Not  supported. 

Programming . Not  supported. 


ORACLE 


Var iable  Length  Fields . Specification  of  field 
lengths  is  required  except  in  the  case  of  LONG  data  types. 
However,  in  all  cases,  space  is  allotted  only  as  required  by 
string  values. 

Maximum  Field  Length . A field  may  contain  a maximum  of 
65,536  characters.  This  is  well  over  the  required  7000  char- 
acters for  the  NRC  database. 

Maximum  Record  Length . Records  may  contain  a maximum 
of  125,256  characters.  This  length  satisfies  the  22,046 
characters  requirement  for  a record  in  the  NRC  database. 

Maximum  Number  of  Fields . The  maximum  number  of  possi- 
ble fields  is  254. 

Repeating  Fields . Not  supported. 

Multiple  Large  Text  Fields . Not  supported  for  text 

fields  that  contain  over  240  characters. 

Indexing . An  index  file  can  be  generated  for  any 
number  of  field  names. 

Searching  Large  Text  Fields . Not  supported  for  text 
fields  that  contain  over  240  characters. 

Repor t Generating . Programming  skills  are  required  to 
generate  the  reports  for  the  NRC  database  application. 

Data  Dumping . Data  dumping  is  handled  through  an  ex- 
port facility  which  allows  extracting  portions  of  a data- 
base. Data  dumping  can  also  be  performed  by  redirecting  the 
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listing  of  a database  file  to  a file  external  to  the  data- 
base . 


Bulk  Loading . Bulk  loading  can  be  performed  from  ei- 
ther a plain  ASCII  file  or  an  exported  data  file.  In  the 
case  of  a plain  ASCII  file,  field  values  have  to  be  fixed  in 
length;  that  is,  the  beginning  and  ending  character  posi- 
tions for  field  values  have  to  be  the  same  across  input 
records . 

Integrity  Checking . Integrity  is  handled  through  a 
screen  building  capability.  This  capability  permits  data 
values  to  be  checked  against  a set  of  allowed  values.  Howev- 
er, pattern  matching  can  be  handled  only  through  its  pro- 
gramming language  interface. 

Structure  modification.  Fields  can  be  appended  to  the 
end  of  a definition  table  or  can  be  increased  in  character 
length.  However,  fields  can  not  be  dropped  from  a table  de- 
finition . 

Maximum  Number  of  Records . The  number  of  records  is 
limited  only  by  the  amount  of  available  storage  space. 

Menu  Building . Menu  Building  is  available  through  the 
high  level  language  interface.  Currently,  C is  the  only 
high  level  language  available  for  interfacing  on  the  PC  fam- 
ily. 

Programming . Programming  is  available  through  the 
external  C language  and  an  internal  PASCAL-like  language. 


REVELATION 


Variable  Length  Fields . Specification  of  field 
lengths  is  not  required  and  is  limited  only  by  the  maximum 
number  of  characters  allowed  per  record. 


Maximum  Record 
65,000  characters. 

Leng  th . 

A record  can 

contain 

up 

to 

Maximum  Field 

Length  . 

A field  can  be 

assigned 

up 

to 

65,000  characters. 

Maximum  Number  of  Fields . The  maximum  number  of  fields 
is  limited  by  the  screen  size.  This  problem  can  be  resolved 
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by  linking  screens.  This  concept  is  called  paging.  Using 
paging  the  maximum  number  of  fields  is  65,000. 

Repeating  Fields . Fields  can  be  either  single  or  mul- 
tivalued. If  a field  is  a multivalued  type,  a set  of  values 
can  be  assigned  to  that  field  for  a single  record  oc- 
currence . 

Multiple  Large  Text  Fields . The  number  of  large  text 
fields  is  limited  only  by  the  number  of  characters  allowed 
per  record.  Thus,  the  number  of  large  text  fields  is  deter- 
mined by  the  selected  partitioning  of  65,000  characters. 

Indexing . The  index  list  can  be  maintained  in  any 
Revelation  file.  The  record  key  is  the  indexed  value.  The 
field  value  is  a multi-valued  list  of  keys  for  the  records 
in  the  file  being  indexed.  Normally,  one  would  create  a 
seperate  cross-reference  file  for  each  Revelation  file  that 
requires  cross  referencing.  The  cross-reference  file  is 
specified  by  name  and  field  number. 

Searching  Large  Text  Fields . The  substring  capability 
allows  searching  any  field  size.  Searches  will  be  performed 
much  faster  on  large  text  fields  that  have  been  indexed. 
Large  text  fields  can  be  indexed  using  the  Revelation  com- 
mand " invert . all"  . 

Report  Generating . Reports  in  the  form  required  by  the 
NRC  database  will  require  programming  capabilities  that  are 
more  detailed  than  the  general  reporting  capabilities. 

Data  Dumping . Data  can  be  dumped  through  the  use  of 
its  BASIC  programming  language  or  its  export  facility  called 
PORTER.  In  either  case,  a plain  ASCII  file  can  be  generated. 
The  copy  command  will  copy  any  group  of  Revelation  records 
to  an  ASCII  file.  Pdisk  from  Revelation  G.2  will  redirect 
printer  output  to  any  DOS  file. 

Bulk  Loading . Data  can  be  bulk  loaded  through  the  use 
of  its  BASIC  programming  language  or  its  import  facility 
called  PORTER.  In  either  case,  field  values  can  be  either 
fixed  or  variable  length.  However,  if  values  are  variable  in 
length,  they  have  to  be  delimited  and  separated  by  commas  or 
some  other  user  specified  character. 

Integr i ty  Checking . Integrity  checking  is  handled 
through  the  use  of  a pattern  matching  capability.  A pattern 
is  set  up  when  a field  is  defined.  It  allows  the  user  to  es- 
tablish editing  criteria  for  that  field.  The  data  entered 
into  that  field  must  match  the  pattern  before  it  can  be  ac- 
cepted by  the  system  as  valid.  A BASIC  program  can  also  be 
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called  to  perform  the  function  of  pattern  matching. 


Structure  Modification.  New  fields  can  be  easily  added 
to  an  existing  structure.  However,  fields  cannot  be  easily 
removed  from  an  existing  structure.  In  Revelation,  the 
file's  dictionary  references  each  field  in  a record  by  its 
field  position.  You  can  remove  a field  with  three  lines  of 
BASIC  code,  and  then  renumber  the  dictionary's  fields,  as 
appropriate.  A better  alternative  would  be  to  null  all  the 
values  for  that  field.  This  would  only  take  one  extra  char- 
acter per  record  in  the  data  base  while  eliminating  the  need 
to  modify  the  dictionary. 

Maximum  Number  of  Records . The  number  of  records  is 
limited  only  by  the  amount  of  available  storage  space. 
Records  may  be  joined  from  multiple  disks. 

Menu  Building . Menu  building  is  available  in  its 
purest  form.  The  menu  building  facility  allows  a developer 
to  tailor  interfacing  to  a database  to  a specific  applica- 
tion „ 


Programming . A version  of  the  BASIC  programming 
language  is  available  and  can  be  accessed  from  within  the 
database  management  system.  This  version  of  BASIC  is 
specifically  designed  for  database  management  and  it  is  an 
integral  part  of  Revelation. 


SCI-MATE 


Variable  Length  Fields . Specification  of  the 
lengths  of  fields  is  not  required  when  defining  a data 
structure.  Storage  is  allotted  character-by-character. 

Max imum  Field  Length . A field  length  is  limited  only 
by  the  maximum  characters  allowed  per  record. 

Max imum  Record  Length . The  maximum  record  length  is 
1,894  characters  per  record.  However,  this  limit  can  be  ex- 
ceeded through  a record  overflow  method.  If  more  than  1,894 
characters  is  assigned  to  a record,  it  will  be  linked  to  an 
overflow  record  which  can  hold  up  to  1,894  characters.  This 
process  is  repeated  until  entry  is  completed  or  the  storage 
space  is  depleted. 

Maximum  Number  of  Fields . Only  20  fields  can  be  speci- 
fied per  record. 
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Repeating  Fields . Not  supported. 


Multiple  Large  Text  Fields . Fields  can  contain  only 
the  1,894-characters  limit. 

Indexing . Not  supported. 

Searching  Large  Text  Fields . Limited  by  the  1,894 
characters  allowed  per  record. 

Report  Generating . Reports  can  be  generated  only  in 
columnar  form.  This  is  inappropriate  for  the  Proposed  NRC 
Database  Structure,  which  has  a minimum  of  44  fields.  For 
example,  if  each  field  was  only  5 characters  wide,  a report 
page  would  be  220  characters  wide.  This  page  width  exceeds 
the  normal  carriage  widths  of  printers  which  are  generally 
80  and  132  characters. 

Data  Dumping . Not  supported. 

Bulk  Loading . Records  can  be  loaded  from  any  text  file 
that  meets  a required  format.  Records  must  be  separated  by 
”****"  and  fields  properly  indicated  by  a coding  scheme. 

Integrity  Checking . Not  supported. 

Structure  Modification . Structure  modifications  can  be 
easily  made.  Fields  can  be  added  or  deleted  at  any  time.  The 
commands  to  do  this  are  menu  driven. 

Maximum  Number  of  Records . The  maximum  number  of 
records  varies  with  record  size  and  available  storage  space. 
For  example,  if  the  available  storage  space  is  10  megabytes 
and  the  record  size  is  102  characters,  the  maximum  number  of 
records  would  be  32,768;  however,  if  the  available  storage 
space  is  10  megabytes  and  the  record  size  is  1,894  charac- 
ters, the  maximum  number  of  records  would  be  5,161. 

Menu  Building.  Not  supported. 

Programming . Not  supported. 
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ANALYSIS  OF  SOFTWARE 


The  recommended  software  is  Revelation,  version  G, 
for  the  development  site.  The  compiled  or  run-time  model  is 
recommended  for  the  distributed  user  sites.  The  respective 
costs  are  $950  and  $200. 

Revelation  is  recommended  over  the  other  packages  be- 
cause it  satisfies  all  of  the  criteria  specified  in  the 
feature  analysis  section  while  the  other  packages  do  not. 
For  example,  Dayflo  does  not  support  menu  building  and  pro- 
gramming. Oracle  does  not  support  repeating  fields,  search- 
ing fields  that  contain  more  than  240  characters,  and 
records  that  contain  more  than  one  field  larger  than  240 
characters.  Sci-mate  is  limited  in  so  many  ways  that  is  not 
necessary  to  elaborate  on  them. 

Future  studies  deal  with  development  of  the  prototype 
database  using  Revelation  and  evaluating  the  performance  of 
the  software  for  this  application. 
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HARDWARE  RECOMMENDATIONS 


The  following  recommendations  are  based  on  the  as- 
sumption that  Revelation  is  to  be  used  as  a DBMS  to  satisfy 
the  requirements.  For  the  development  of  the  proposed  NRC 
database  and  for  high-usage  sites,  an  IBM  AT  or  equivalent 
with  the  following  configuration  is  recommended: 


Item  Price 


30  Megabyte  fixed  disk  (internal) 
1.2  Megabyte  floppy  disk 

$4,196 

512  K RAM  memory 
Serial/parallel  adapter 

105 

360  Kilobyte  floppy  disk 

297 

80287  Math  Coprocessor 

262 

Monitor  adapter 

175 

Monitor  (monochrome) 

192 

Hayes  2400S  modem  (external) 

675 

IBM  Quietwriter 

947 

9 Pin  Serial  adapter  (with  an  RS232 

conversion)  25 

Printer  cable 

25 

RS232  serial  cable 

44 

20+  Megabyte  Bernoulli 

3,756 

Total 

$10,699 

Cost  with  an  Epson  FX-85 

printer 

$10,102 

The  20.  megabyte  fixed  disk  (internal)  , 1.2  megabyte  floppy 
disk , and  512K  RAM  memory  are  sold  as  a unit  price.  The 
80287  math  coprocessor  is  recommended  by  the  producers  of 
Revelation  for  improving  the  performance  of  the  software. 
The  monitor  adapter  should  be  a monochrome  card  for  better 
screen  resolution.  The  Hayes  1200S  modem  will  be  use  to 
communicate  with  other  distributed  sites.  The  IBM  Quietwr it- 
er is  recommended  because  of  its  report  quality  and  dot  ma- 
trix capabilities.  The  9 pin  serial  adapter  is  necessary 
since  the  serial/parallel  card,  which  is  standard  with  the 
enhanced  AT,  has  a 9 pin  serial  port  which  is  not  compatible 
with  the  standard  25  pin  RS232  serial  port.  The  2J3+  Mega- 
byte Bernoulli  is  recommended  because  of  its  storage  volume 
as  a data  transfer  medium.  Additionally,  it  is  recommended 
that  the  development  site  acquire  copies  of  the  DOS  3.1,  DOS 
technical,  and  the  AT  technical  reference  manuals. 

For  low-usage  sites,  an  IBM  XT  or  equivalent  (i.e.,  an 
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IBM  PC  upgrade)  with  the  following  configuration  is  recom- 
mend : 


Item  Price 


43  Megabyte  fixed  disk  (internal) 

360  Kilobyte  floppy  disk  $2,942 

256  K RAM  memory 

Ast  6 Pak/with  256K  RAM  318 

8087  Math  Coprocessor  145 

Monitor  adapter  175 

Monitor  (monochrome)  192 

Epson  FX-85  350 

2400  baud  modem  (external)  675 

Printer  cable  25 

RS232  Serial  cable  44 

20+  Megabyte  Bernoulli  3,756 

Total  $8,622 


The  4_3  megabyte  fixed  disk  (internal)  , 360  kilobyte  floppy 
disk , and  256K  RAM  memory  are  specified  as  a unit  pr ice . To 
get  the  additional  256K  RAM  of  memory,  the  AST  6 Pak  card  is 
required.  The  8087  math  coprocessor  is  needed  to  improve  the 
performance  of  Revelation.  The  IBM  monochrome  card  has  both 
monitor  and  parallel  adapters.  The  Epson  FX-85  is  recom- 
mended for  the  same  reason  as  previously  stated.  The  20 
Megabyte  Bernoulli  is  recommended  for  the  same  reason  as 
previously  stated. 

Futhermore,  as  a minimum  configuration,  an  IBM  PC  could 
be  configured  with  the  following  hardware,  with  the  under- 
standing that  it  would  be  used  in  conjunction  with  a Ber- 
noulli as  discussed  in  the  text  of  the  report. 


I tern  Price 


IBM  PC with  $1606.00 

256K  RAM 

2 DS/DD  floppy  drive 
keyboard 

Monitor  Adapter  Card  175.00 

AST  6 Pak  w/256K  318.00 

8087  Math  Coprocessor  161.00 

IBM  Mono  Monitor  192.00 

Epson  FX8 5 350.00 

Printer  Cable  25.00 

2400  Baud  Modem  (external)  675.00 
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A Bernoulli  Controller  Card 
RS232  Serial  Cable 


130.00 

44.00 


Total 


$3,676.00 


Backup  storage  media  have  been  omitted  from  the  above, 
because  floppy  diskettes  and  the  20  megabyte  Bernoulli 
carteriages  can  be  used  initially.  After  the  database  has 
grown  too  large  for  floppys  to  be  effective  and  practical, 
it  is  anticipated  that  very  economical  alternatives  with 
very  high  storage  capacities  and  quick  access  times  will  be 
on  the  market  at  relatively  low  cost,  when  compared  with  the 
backup  hardware  that  is  now  marketed. 

In  addition  to  the  frequency  of  usage  per  week,  another 
criteria  for  recommending  an  IBM  AT  over  an  IBM  XT  is  the 
response  time  when  searching  large  volumes  of  text.  The  IBM 
XT  should  be  regarded  as  a machine  for  use  only  when  indexed 
items  are  to  be  searched.  The  reason  for  this  is  that  search 
time  on  large  volumes  of  text  is  likely  to  be  in  terms  of 
minutes  even  when  the  AT  is  used;  therefore,  use  of  an  XT 
for  such  searches  is  impractical  because  the  AT  runs  twice 
as  fast  as  the  XT. 
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APPENDIX  I 


A Preliminary  File  Structure  Used  to  Develop 
Software  and  Hardware  Recommendations 


PROPOSED 

NF 

Data 

element 

1 

Data 

element 

2 

Data 

element 

3 

Data 

element 

4 

Data 

element 

5 

Data 

element 

6 

Data 

element 

7 

Data 

element 

8 

Data 

element 

9 

Data 

element 

10 

Data 

element 

11 

Data 

element 

12 

Data 

element 

13 

Data 

element 

14 

Data 

element 

15 

Data 

element 

16 

Data 

element 

17 

Data 

element 

18 

Data 

element 

19 

Data 

element 

20 

Data 

element 

21 

Data 

element 

22 

Data 

element 

23 

Data 

element 

24 

Data 

element 

25 

Data 

element 

26 

Data 

e ] 

27 

Data 

element 

28 

Data 

element 

29 

Data 

element 

30 

Data 

element 

31 

Data 

element 

32 

Data 

element 

33 

Data 

element 

34 

Data 

element 

35 

Data 

element 

36 

Data 

element 

37 

Data 

element 

38: 

Data 

element 

39: 

) 

to  50  chars 
5 numbers) 


) 


Citation  No.  (8  chars.) 

Publication  type  (10  chars 
Authors  (10  to  110  chars.) 

Editors  of  Publication  (10 
Article  No.  (1  letter  plus 
Article  Title  (100  chars.) 

Publication  Series  (30  chars.) 

CODEN  (10  chars.) 

Vol.,  Ed.  or  No.  (2  numbers) 

Issue  (2  numbers) 

Page  (3  numbers) 

Contract  No.  (6  chars,  plus  5 numbers) 

Publication  Date  (8  chars.) 

Publisher,  City,  State  (100  chars.) 

Sponsor  and  Address  (100  chars.) 

Site  Address  (60  chars.) 

Patent  Nos.  (9  numbers) 

Application  or  Meeting  Date  (8  chars.) 

Dissertation  Degree  (15  chars.) 

Date  of  last  Data  record  update  (6  numbers) 

Country  of  Patent  issue  (10  chars.) 

No.  of  Authors  (2  chars.) 

Country  (Authors)  (12  chars.) 

Language  (8  chars.) 

ISSN,  ISBN  (10  chars.) 

Abstract  Source  (15  chars.) 

Abstract  Nos.  (6  numbers) 

Related  Citation  Nos. 

(0  to  36  numbers;  6 numbers  repeating  up  to  6 times) 
CA  Registry  No.  (6  numbers) 

Availability  (15  chars) 

Document  Key  Words  (60  to  200  chars.) 

Property  and  Form  of  Data  Comments  (10  to  1200  chars. 
Property  and  Form  of  Data  Keywords  (50  chars.) 
Materials  and  Specimen  Geometry  Comments 
(50  to  1200  chars.) 

Materials  and  Specimen  Geometry  Key  Words  (50  chars.) 
Test  Conditions  Comments  (50  to  1800  chars.) 

Test  Conditions  in  temperature 
(5  numbers,  repeating  up  to  12  times) 

Test  Conditions  in  pressure 
(5  numbers,  repeating  up  to  12  times) 

Test  Conditions  in  time 

(5  numbers,  repeating  up  to  12  times) 
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Data 

element 

40 

Data 

element 

41 

Data 

element 

42 

Data 

element 

43 

Data 

element 

44 

Experimental  Methods  (100  chars.) 

Comments  on  Data  Validity  and  experimental  methods 
(500  chars.) 

Document  Abstract  400  to  4000  (chars.) 

Comments  on  Computational  analysis  (70  to  5000  chars.) 
Executive  Summary  (2000  to  7000  chars.) 
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APPENDIX  II 


IMPLEMENTATION  OF  REVELATION  FOR  A HLW  DATABASE: 


A.  SCHEMA  FOR  A HIGH  LEVEL  WASTE  DATABASE 

B.  REVIEWER’S  INSTRUCTIONS  FOR  THE  WASTE  PACKAGE  DATA  REVIEW  FORM 

C.  LIST  OF  DATA  ELEMENTS  FOR  THE  BIBLIOGRAPHIC  FILE  AND  THEIR 
DESCRIPTIONS 

D.  SAMPLE  OF  A COMPLETED  REVIEW 

E.  SAMPLE  OF  BIBLIOGRAPHIC  CITATIONS 
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APPENDIX  IIA 


SCHEMA  FOR  A HIGH  LEVEL  WASTE  DATABASE 
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Schema  for  a High  Level  Waste  Database 


2/14/86 


General  Data  Element  Categories  Containing  Content  Description 

C - Data  Element  is  not  Limited  to  a Keyword  List 
K - Data  Element  is  Limited  to  a Preset  Keyword  List 
M * Multiple  Entries  Permitted  in  a Data  Element 
N - Numerical  Data  Element 

S - Single  Entry  Permitted  in  a Data  Element 

1 

Titles  for  the  Checklists  of  Keywords 

1.  Scope  of  Work  (M,K) 

2.  Model/Methodology  (M»K) 

3.  General  Environment  (M,K) 

4.  Water  Present  (M,K) 

5.  Other  Materials  Present  in  the  Environment  (M,C) 

6.  Material  Studied  (General  Type)  (M,K) 

7.  Material  Studied  (Standard  Designation)  (M,C) 

8.  Material  Condition  Prior  to  Tests  (M,K) 

9.  Electrolytes  (M,K) 

10.  Radionuclides  and  Material  Containing  Them  (M,K) 

11.  Measurements  (M,K) 

12.  Mechanical  and  Thermophysical  Properties  (M,K) 

13.  Failure  Modes  or  Phenomena  Studied  (M,K) 


General  Comment  Data  Elements  from  the 
WASTE  PACKAGE  DATA  REVIEW  FORM 
(their  relationship  to  Checklists  1 to  13) 

1.  Type  of  Data  (1.,  13.)  (S,C) 

2.  Materials/Components  (6.,  7.)  (S,C) 

3.  Test  Conditions  (12.,  3.,  4.,  5.,  8.,  9..,  10.)  (S,C) 

4.  Method  of  Data  Collection/Analysis  (11.,  2.)  (S  ,C) 

5.  Amount  of  Data  (Data  and  Graph  Summary  Tables)  (S,C) 

6.  Uncertainties  in  Data  (S,C) 

7.  Deficiencies/Limitations  in  Data  Base  (S,C) 

8.  General  Comments  (S ,C) 

9.  Abstract  (if  any)  from  HLW  entry  (S,C) 
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Schema  for  a High  Level  Waste  Database  2/14/86 


Summary  of  Graphs  z = f(X,Y)  z = property  studied 

X = variable  on  x axis 
Y = variable  on  y axis 

1.  Property  Measured  (S,K) 

2.  Property  of  X Variable  (S,K) 

3.  Units  of  X Variable  (S,K) 

4.  Minimum  of  X Variable  (S,N) 

5.  Maximum  of  X Variable  (SfN) 

6.  Property  of  Y Variable  (S,K) 

7.  Units  of  Y Variable  (S,K) 

8.  Minimum  of  Y Variable  (S,N) 

9.  Maximum  of  Y Variable  (S,N) 

10.  Figure  Title  (S,C) 


Data  Summary  Table  z = f(X,Y,t)  where 

z = property  studied 
t = time 

X = X variable  (such  as  Temperature) 
Y = Y variable  (such  as  Pressure) 

1.  Property  Studied  (name  of  z)  (S,K) 

2.  Numerical  Value  of  z (S,N) 

3.  Units  of  z (S,K) 

4.  Uncertainty  of  z assigned  within  HLW  entry  (S,N) 

5.  Name  of  X variable  (S,K) 

6.  Numerical  Value  of  X (S,N) 

7 . Units  of  X (S ,K) 

8.  Name  of  Y variable  (S,K) 

9.  Numerical  Values  of  Y (S,N) 

10.  Units  of  Y (S,K) 

11.  Numerical  Time  Value  (t)  (S,N) 

12.  Time  Unit  Name  (S,K) 

13.  Table  Title  (S,C) 
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CM  CM  CM  CM  CM  CM 


KEYWORD  CHECKLISTS 


2/14/86 


1. 

1. 

1. 

1. 

1. 

1. 

1. 

2. 


3. 

3. 
3 . 
3. 
3 . 
3. 
3 . 
3. 
3. 
3. 
3. 
3. 


Scope  of  Work 

_____  data  analysis 

experimental  data 
literature  review 
_ planned  work 
theory 
other 


Model/Methodology 

__  Latin  Hypercube 
Monte  Carlo 

__  PDF  (probability  distribution  functions) 

_ sampling 
. scoping  test 

other  


General  Environment 

J-13  water 
basalt 
field  site 
granite 
_____  laboratory 

radiation  field  (alpha) 
radiation  field  (gamma) 
salt 

simulated  field  site 

tuff 

other 


(M,K) 


(M,K) 


(M,K) 


4.  Water  Present 


(M,K) 


4. 
4. 
4. 
4. 
4. 
4. 
4. 
4. 
4. 
4 . 
4. 
4. 


J-13  water 
PH 

basalt  composition 

brine 

deionized 

flow  rate 

granite  composition 
redox  condition 
salt  concentration 

significant  dissolved  species  concentration 

tuff  composition 

other 
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KEYWORD  CHECKLISTS 


2/14/86 


5. 

Other  Materials  Present  in  the  Environment 

(M.C) 

5. 

l_  ci 

5. 

| Cu 

5. 

1 Fe 

5. 

| J-13  water 

5. 

| Keller's  reagent 

5. 

| Ni 

5. 

| sulfur  ions 

5. 

| other 

6. 

Material  Studied  (General  Type) 

(M,K) 

6. 

| brass 

6. 

j bronze 

6. 

| cast  iron 

6. 

| cladding 

6. 

j copper  base 

6. 

| electrolyte 

6. 

1 general  environment 

6. 

| nickel  base 

6. 

| packing 

6. 

| radionuclide 

6. 

| stainless  steel 

6. 

| steel 

6. 

| titanium  base 

6. 

| water 

6 „ 

| weld 

6. 

j zircaloy 

6. 

| zirconium  base 

6. 

| other 

7. 

Material  Studied  (Standard  Designation) 

(M,C) 

7. 

| 304  stainless  steel 

7. 

j 304L  stainless  steel 

7. 

| 308L  weld  filler  wire 

7. 

| 316L  stainless  steel 

7. 

| AISI  317L 

7. 

| AISI  321 

7. 

| AISI  347 

7. 

| AISI  1020 

7. 

| AISI  1025 

7. 

| J-13  steam 

7. 

| J-13  water 

7. 

bentonite 

7 . 

| deaerated  distilled  water 

7. 

| distilled  water 

7. 

| grey  cast  iron 

7 . 

| high-nickel  alloy  825 

7 . 

| nodular  cast  iron 

7 . 

| zircaloy-4 

7 . 

i other 
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KEYWORD  CHECKLISTS 


2/14/86 


8. 

Material  Condition  Prior  to  Tests 

(M,K) 

8. 

j case  hardened 

8. 

| cast 

8. 

i cold  worked 

8. 

| irradiated 

8. 

| magnetized 

8. 

| mill  annealed 

8. 

| prestressed 

8. 

J sensitized 

8. 

| sintered 

8. 

| solution  treated 

8. 

1 stress  relieved 

8. 

j textured 

8. 

| welded 

8. 

| wrought 

8. 

I other 

9 . 

Electrolytes 

(M,K) 

9. 

j J-13  water 

9. 

| acetic 

9. 

| alkaline 

9. 

| aerated 

9. 

| chloride 

9. 

| deaerated  distilled  water 

9. 

| irradiated 

9. 

| neutral 

9. 

| other 

10. 

Radionuclides  and  Materials  Containing  Them 

(M,K) 

10. 

| Co60 

10. 

1 Np237 

10. 

| Pu239 

10. 

| commercial  high  level  waste  (CHLW) 

10. 

| defense  high  level  waste  (DHLW) 

10. 

| spent  fuel  (power  reactors) 

10. 

| spent  fuel  (water  reactors) 

10. 

| other 

KEYWORD  CHECKLISTS 


2/14/86 


11. 

Measurements 

11. 

adsorption 

11. 

electrochemical 

11. 

microscopy 

11. 

neutron  diffraction 

11. 

slow  strain  rate 

11. 

sorption 

11. 

spectroscopy 

11. 

surface  film 

11. 

tensile  test 

11. 

thermal  history 

11. 

visual  examination 

11. 

weight  change 

11. 

x ray  diffraction 

11. 

1 

other 

CM 

«— 1 

Mechanical  and  Thermophy 

12. 

bent  beam  tests 

12. 

creep  strength 

12. 

density 

12. 

elongation 

12. 

heat  (conduction) 

CM 

H 

heat  (convection) 

12. 

heat  (radiative) 

12. 

heat  capacity 

12. 

hydrostatic  head 

12. 

lithostatic  pressure 

12. 

modulus  of  elasticity 

12. 

stress  - strain 

12. 

tensile  strength 

12. 

thermal  conductivity 

12. 

thermal  expansion 

12. 

yield  strength 

12. 

1 

other 

AO 


(M,K) 


(M,K) 


KEYWORD  CHECKLISTS 


2/14/86 


13.  Failure  Modes  or  Phenomena  Studied 


13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 

13. 


buckling 

corrosion  (crevice) 
corrosion  (general) 
corrosion  (intergranular) 
corrosion  (local) 
corrosion  (microbial) 
corrosion  (pitting) 
corrosion  (stray  current) 
corrosion  (stress  cracking  - SCC) 
creep 

creep  buckling 

dealloying 

debonding 

deformation  (elastic) 
deformation  (plastic) 
degradation  (spent  fuel) 
devitrification  (glass) 
diagenetic- like  changes 
fatigue  (corrosion) 
fatigue  (high  cycle) 
fatigue  (low  cycle) 
fatigue  (thermal) 
fracture  (brittle) 
fretting 
galvanic 

hydration  (glass) 

hydrogen  attack  (CH3  formation) 

hydrogen  embrittlement 

leaching  (radiation  enhancement) 

leaching  (spent  fuel) 

matrix  dissolution  (glass) 

passivity 

poisoning  (chemical) 
radiation  effects 
relaxation  (thermal) 
rupture  (ductile) 
rupture  (stress) 
sensitization 
spalling 

thermal  instability 
other 


(M,K) 
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APPENDIX  I IB 


REVIEWER'S  INSTRUCTIONS  FOR  THE  WASTE  PACKAGE  DATA  REVIEW  FORM 
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DRAFT :RShull: 1-30-86 


TYPE  OF  DATA: 

(1)  Scope  of  the  Report:  e.g.,  Experimental,  Theoretical,  Literature 

Review,  Data  Analysis 

(2)  Failure  Mode  or  Phenomenon  Studied:  e.g..  Corrosion,  Creep, 

Fatigue,  Leaching,  Pitting,  Hydrogen 
Embrittlement,  Debonding,  Dealloying 


MATERIALS/COMPONENTS: 

Description  of  the  material  studied  (or  component  part,  if  specifically 
addressed  as  such;  e.g.,  the  screw-on  type  cap  on  a waste  cylinder): 
e.g.,  304L  Stainless  Steel,  Brass,  Zircalloy  Cladding,  Welds  in  316 
Stainless  Steel,  Packing  Material,  Basalt 


TEST  CONDITIONS: 

Includes  (1)  the  State  of  the  material  being  tested,  and  (2)  the 
Environment  of  the  material  being  tested,  e.g.: 

(1)  Cold  worked  or  annealed  304L  Stainless  Steel,  Thermo-mechanical 
history  of  the  material  (or  component)  being  studied 

(2)  Aqueous  environment,  Radioactive  surrounding.  Electrolytes  or 
corrosive  agents  present,  Temperature  and  pressure  (externally 
applied  or  not)  during  the  test 

METHODS  OF  DATA  COLLECTION/ANALYSIS: 

Includes  Data  Measurement  Methods  and  Types  of  data  measured,  as  well 
as  Data  Analysis  Techniques,  e.g.: 

Electron  microscopy,  weight  loss  vs.  time,  slow  strain  rate  tensile 
test,  x-ray  diffraction,  differential  thermal  analysis,  A.C.  electrical 
resistivity  using  a Wheatstone  bridge,  mass  spectroscopic  chemical 
analysis  of  the  corrosive  environment,  Latin  Hypercube  method,  Monte 
Carlo  techniques 


AMOUNT  OF  DATA: 

Includes  the  number  of  tables  and  graphs  of  data  together  with  their 
titles  and  axes  (indicating  the  range  in  values),  e.g.: 

5 tables  of  temperature  and  time  data  for  five  molten  glass  pouring 
operations,  each  table  including  the  data  from  ten  sensor  locations. 
The  temperatures  ranged  from  1100  °C  to  0 °C  over  a time  period  of  24 
hours . 
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UNCERTAINTIES  IN  DATA: 


Included  here  are  error  bars  and  uncertainties  in  the  data  as  stated 
by  the  author.  This  also  includes  qualitative  statements  by  the 
author  on  the  reliability  of  the  data,  e.g.: 


Temperatures  carry  an  accuracy  of  ±5  °C  while  the  times  are  reported 
to  within  ±15  sec.  It  was  felt  that  under  real  glass  pouring 
operations  (without  well  controlled  crucible  cooling)  the 
temperature-time  curves  will  be  shifted  to  somewhat  higher 
temperatures  than  shown  here. 


DEFICIENCIES/LIMITATIONS  IN  DATABASE: 

Includes  statements  by  the  author  on  the  applicability  of  the  data, 
e.g. : 

Extrapolation  of  the  temperature-time  (time  < 24  hrs)  data  presented 
here  to  times  in  excess  of  100  years  should  not  be  performed.  The 
data  presented  here  is  useful  only  for  indicating  trends  and 
qualitative  parameter  relationships,  not  for  the  purpose  of  presenting 
absolute  values. 


APPLICABILITY  OF  DATA  TO  LICENSING: 

Includes  information  pertaining  to  specific  Listed  Licensing  Issues  in 
an  NRC  site  characterization  plan  (ISTP).  If  an  issue  is  specifically 
addressed  in  the  paper,  then  the  "key  data"  box  should  be  marked. 
Otherwise,  the  paper  is  "supporting  data."  Comments  on  the  listing  of 
the  document  under  subcategories  (a)  and  (b)  may  be  made  in  those 
subsections.  The  comments  section  in  this  category  are  the  reviewer’s 
comments  pertaining  to  licensing. 


GENERAL  COMMENTS: 

The  reviewer  * s general  comments  on  the  document.  This  category  is 
wide  open  as  far  as  content.  It  contains  information  the  reviewer  did 
not  enter  in  any  of  the  above  categories,  but  which  is  considered 
important  for  the  reader  to  know,  e.g.: 

This  is  a very  comprehensive  review  of  the  literature  on  the 
temperature  sensitization  of  stainless  steels.  Even  though  it 
neglects  the  definitive  work  of  Bertocci , Shull,  Kaufman,  and 
Escalante  [Phys.  Rev.  J 1 3 . (1879),  pp.  15-358]  in  this  area 
(presumably  because  of  the  difficulty  in  locating  this  document), 
this  review  still  considers  a sufficiently  large  number  of  other 
investigations  to  provide  a good  understanding  of  the  present 
status  of  the  field.  The  one  discordant  note  here,  however,  is  that 
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vMM 


it  would  have  been  a much  more  useful  review  if  stainless  steel  types 
301,  303,  304,  316,  and  440C  had  also  been  addressed* 

It  would  be  in  this  section  that  the  reviewer's  own  comments  on  the 
deficiencies  and  uncertainties  in  the  data  and  analysis  would  appear* 


DATA  SOURCE: 

Full  document  reference.  This  section  will  be  completed  for  the 
reviewer  before  he/she  receives  the  document. 


KEY  WORDS: 

These  are  already  entered,  as  they  are  included  in  the  entries  of  the 
above  categories. 


DATE  REVIEWED: 

The  date  the  document  review  was  completed. 


Directory  for  Key  Word  List  Completion 


The  following  is  a listing  of  the  major  headings  of  the  Waste  Package  Data 
Review  Form  indicating  (both  by  title  and  list  numbers)  which  key  word 
lists  may  be  filled  out  by  the  reviewer  from  the  information  that  appears 
in  that  review  form  heading. 


TYPE  OF  DATA:  Scope  (1),  Failure  Mode  (13) 

MATERIALS/COMPONENTS:  Material  Studied  (6,  7) 

TEST  CONDITIONS:  (a)  State  of  the  Material  (5,  8,  12) 

(b)  Tests  (3,  4 , 9,  10)... 

METHOD  OF  DATA  COLLECTION:  Measurement  Type  (11) 

Model  (2) 


AMOUNT  OF  DATA:  . Number  of  tables,  graphs,  and  titling 
numerical  results  and  their  axes  and 
ranges 


UNCERTAINTIES  IN  DATA: 

DEFICIENCIES /LIMITATIONS  IN  DATABASE: 

APPLICABILITY  OF  DATA  TO  LICENSING: 

(a)  Relationship  to  'Waste  Package  Performance  Issues  Already 
Identified 

(b)  New  Licensing  Issue 

(c)  Comments 

GENERAL  COMMENTS: 

DATA  SOURCE: 

KEY  WORDS:  From  List  of  Elements 
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APPENDIX  IIC 


LIST  OF  DATA  ELEMENTS  FOR  THE  BIBLIOGRAPHIC  FILE  AND  THEIR  DESCRIPTIONS 
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DATA  ELEMENTS  LIST  FOR  THE  BIBLIOGRAPHIC  FILE 


Entry  Program  for  HLW  Reference  File  (1-1) 


HLW . 

ENTRY 

01 

CIT . NO 

02 

PUB. TYPE 

03 

AUTHOR . S 

CA 

EDITOR. S 

05 

CHAP. NO 

05 

SUB. TITLE 

07 

PUB. TITLE 

03 

PUB.ORG 

09 

PUB. SPONSOR 

10 

SITE. REL 

1 1 

PUB. AVAIL 

1 2 

PUB. NO 

1 3 

CONTRACT.NO 

1 A 

pat.no 

15 

PUB. VOL 

16 

PUB. ISSUE 

1 7 

PUB. PAGE 

13 

PUB. CODEN 

19 

PUB. ISSN 

20 

PU3. DATE 

21 

OTHER. DATE 

21 

START. DATE 

23 

CHANGE. DATE 

2 A 

CIT. REL 

AH 


Descriptions  of  the  Bibliographic  Data  Elements 


01  CIT .NO 

A unique  NBS-assigned  reference  number  assigned  to  every  entry  in  the  HWL 
collection . 


02  PUB. TYPE 

The  form  of  the  publication:  1 general;  2 journal;  3 book;  4 conference; 

5 patent;  6 magnetic  media;  7 dissertation;  8 draft  or  in  press; 

9 communication. 

03  AUTHOR. S 

The  persons  (not  organizations)  who  created  the  entry.  The  patronymic 
name  comes  first  (i.e.,  Smith,  W.  L.  A.,'  Jr.,  or  O'Ryan,  C.)„ 


04  EDITOR. S 

The  editors  and/or  translators  of  the  entry  (not  the  N3S  or  other 
reviewers ) . 


05  CHAP. NO 

A number  pertinent  to  the  entry  such  as  article  number,  chapter  number, 
conference  paper  number,  or  report  number  within  a larger  document. 


06  SUB. TITLE 

The  subtitle  of  the  pertinent  section  within  a HLW  entry  such  as:  \ an 

article  title;  2 chapter  title  in  a book;  3 journal  paper  or  report  title 
within  a conference  report. 


07  PUB. TITLE 

HLW  entry  title:  1 book  title;  2 journal  title;  3 report  series  name; 

4 conference  or  proceedings  name;  5 dissertation  series  name. 

08  PUB.ORG 

The  name  and  possibly  a short  address  of  the  organization  that  created  the 
HLW  entry. 
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09  PUB. SPONSOR 


The  name  and  address  cf  the  sponsoring  organization:  i contract  report 

sponsor;  2 conference  sponsor;  3 patent  sponsor. 


10  SITE . REL 

Additional  site  locations  if  needed  such  as:  1 meeting  place  of 

conference  (if  not  included  in  the  title);  2 university  cf  dissertation. 


11  PUB. AVAIL 

Availability  of  the  document  to  the  general  public,  and  ordering 
inf  ormation . 


12  PUB. NO 

The  number  or  numbers  assigned  to  the  HLW  entry  by  the  creating 
organizations  for  cataloging  purposes  (i.e.,  an  ORNL  number,  a NUREG 
number , etc . ) . 

13  C0NTRACT.N0 

The  contract  number  under  which  the  report  was  generated.  There  may  be 
more  than  one  report  under  a contract  number. 


14  PAT. NO 

°atent  number,  patent  pending  number. 


15  PUB. VOL 

1 volume  number  of  journal;  2-  edition  of  book;  3 number  cf  conference  or 
proceedings . 


16  PUB. ISSUE 

The  issue  number  of  a journal  or  publication. 

17  PUB. PAGE 

The  page  number  of  document  (start-end),  or  total  pages 
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IS  PUB . CODEW 


The  AST!'  CCDEN,  with  check  character,  as  assigned  by  the  Chemical 
Abstracts  Services.  A CODEN  is  a six  character  code  describing  a serial 
publication  such  as  a journal. 


19  PUB. ISSN 

The  International  Standard  Serial  Number  (ISSN)  or  the  International 
Standard  Book  Number  (ISBN). 


20  PUB. DATE 

The  date  of  publication,  issue  date  of  patent,  or  date  of  conference 
proceedings  publication  (not  meeting  date,  see  OTHER. DATE)  . 


21  OTHER. DATE 

Any  additional  date  needed  to  describe  the  publication,  as  date  of  patent 
application,  or  date  of  conference  meeting. 


’22  START. DATE 

This  is  the  date  that  this  data  entry  was  created. 

23  CHANGE. DATE 

This  is  the  date  that  this  data  entry  was  last  changed. 


29  CIT.REL 


The  internal  (NBS)  numbers  of  other  entries  in  the  HLVJ  data  collection 
that  are  directly  related  to  this  entry. 
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APPENDIX  IID 


SAMPLE  OF  A COMPLETED  REVIEW 
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WASTE  PACKAGE  DATA  REVIEW  FORM 


TYPE  OF  DATA 


Experimental  study  of  the  possible  effects  of  a 3~year  exposure  of  a 30^L 
canister  in  Climax  stock  quartz  mangonite  and  the  implications  for  waste 
disposal  in  a tuff  environment.  The  canister  was  examined  by 
metallurgical  examination  and  chemical  analysis,  and  the  water  taken  from 
the  liner  rock  annulus  was  also  analyzed  for  smilarities  with  anticipated 
tuff  water  chemistry. 


MATERIALS/COMPONENTS 


3041,  canister  with  308L  weld  filler  wire;  plain  C steel  liner 


TEST  CONDITIONS 


Three-year  exposure;  underground  granite;  canister  containing  spent  fuel; 
water  containing  a significant  concentration  of  dissolved  species 
(including  Cl)  in  contact  with  base  of  the  welded  30^L  canister-  maximum 
temperature  - 1 MO  °C;  ambient  pressure;  total  Y dose;  3.2  x 10°  rads 


METHODS  OF  DATA  COLLECTION/ANALYSIS 


Metallographic  observation  after  exposure;  thermocouple  measurements 
during  storage;  chemical  analysis  of  canister  materials  and  well  water 
before  and  after  exposure 


AMOUNT  OF  DATA 


One  table  comparing  water  analysis  of  Climax  facility  with  J-13  well 
water;  one  table  listing  results  of  chemical  analysis  of  base  metal,  welc 
metal,  and  weld  wire;  one  graph  of  temperature  (20  - 120  °C)  vs.  time 
(2.^4  - 3.6  yrs)  for  the  canister  and  liner 


UNCERTAINTIES  IN  DATA 


Not  addressed. 


DEFICIENCIES/LIMITATIONS  IN  DATABASE 

The  authors  discuss  the  validity  of  using  the  data  from  this  environment 
for  predicting  the  behavior  in  a tuff  repository  and  conclude  that  the 
environment  studied  Is  more  aggressive  than  the  tuff  environment 
indicating  that  the  performance  of  BO^L  in  tuff  should  be  adequate  for 
repository  purposes. 
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APPLICABILITY  OF  DATA  TO  LICENSING 


[Ranking:  key  data  ( ),  supporting  data  (X)] 

(a)  Relationship  to  Waste  Package  Performance  Issues  Already  Identified 

The  data  are  considered  supporting  for  issues  2.2  and  2.2.1  in  the 
ISTP  for  NNWSX. 

(b)  New  Licensing  Issues 

(c)  General  Comments 

DATA  SOURCE 

(a)  Organization  Producing  Data 

Lawrence  Livermore  National  Laboratory,  Livermore,  CA  94550 

(b)  Author(s),  Reference,  Reference  Availability 

Weiss,  H.,  Van  Konynenburg,  R.  A.,  and  McCright,  R.  D.,  Metallurgical 
Analysis  of  a 304L  Stainless  Steel  Canister  from  the  Spent  Fuel 
Test — Climax,  UCID-20436,  April  1985.  Available  from  NTIS. 

KEY  WORDS  (These  will  he  generated  from  the  Keyword.  Checklist.  ) 


GENERAL  COMMENTS 


The  authors  suggest  in  their  discussion  that  more  severe  chloride  cracking 
occurs  at  the  lower  temperatures  encountered  in  the  spent-fuel  test  than 
at  the  higher  temperatures  expected  for  the  repository.  This  is 
questionable  based  on  previous  work  done  in  these  alloys  over  a range  of 
temperatures.  For  example,  Kowaka  and  Kudo  (Trans.  JIM,  J_6  (1925)  385) 
show  time  to  failure  (t^)  curves  for  304  as  a function  of  temperature 
where  there  is  a minimum  in  t^  at  approximately  140  °C.  Thus,  it  would  be 
useful  to  perform  similar  experiments  at  slightly  higher  average 
temperatures  (i.e.,  130  - 145  °C)  where  SCC  is  most  pronounced. 


DATE  REVIEWED:  10-28-85/Revised  12-2-85/1-13-86 
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SAMPLE  OF  BIBLIOGRAPHIC  CITATIONS 
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f'  Mtnc.  ■ i 

NW. REF  DATA 


13:  30:  06  Ob  0£d  1985 


001  Cit:  001  .'Authors:  Claiborne,  H.C.jCroff,  A.  6.  ; Griess, 

J.C.jSmith,  F.J.  iPub. title:  Repository  Environmental  Parameters 

Relevant  to  Assessing  the  Performance  o-f  High-Level  Waste 
Packages  in  Basalt,  Tuff , and  Salt  iPub.org:  OAK  RIDGE  NATIONAL 

LABORATORY,  Oak  Ridge,  Tennessee  37831  operated  by  MARTIN 
MARIETTA  ENERGY  SYSTEMS,  INC.  i Pub . sponsor : Division  of  Waste 
Management,  Office  of  Nuclear  Material  Safety  and  Safeguards, 

NRC , Wash.,  DC  20555  iPub.no:  NUREG/CR-4 134; 0RNL/TM-9522/R1 

i Contract . no:  NRC  FIN  NO.  B0288  i Pub. page:  338  i Pub. date: 

09/00/85  !P:  1 iStart.date:  12-06—85  i Change. date:  12-06-85 

002  Cit:  002  .Authors:  Stephens,  K.;Boesch,  L.jCrane,  B. ; Johnson, 
R.;Moler,  R.;Smith,  S.jZaremba,  L.  IPub. title:  Methodologies  for 
Assessing  Long-Term  Performance  of  High-Level  Radioactive  Waste 
Packages  iPub.org:  Eastern  Technical  Division,  THE  AEROSPACE 
CORPORATION,  Wash.,  DC,  ! Pub . sponsor : Office  of  Nuclear  Material 
Safety  and  Safeguards,  NRC,  Wash.,  D,.C.  iPub.no: 

ATR-85 (5810— 01 ) — 1ND  SContract.no:  F04701— 83-C— 0084  i Pub. page:  188 

iPub.date:  05/00/85  iP:  1 ! Start . date:  12-06-85  ! Change. date: 

12-06-85 

003  Cit:  003  {Authors:  Ballou,  Lynden  B.;McCright,  R.  Daniel 
!Pub. title:  Overview  Information  on  NNSWI’s  Corrosion  Program 
iPub.org:  Lawrence  Livermore  National  Laboratory  iPub.no: 

MRB-0418  iPub.date:  03/08/85  SP:  9 iCit.rel:  004;005  iStart.date: 
10-25-85  i Change. date:  10-25-85 

004  Cit:  004  'Authors:  Ballou,  Lynden  B.jMcCright,  R.  Daniel 

! Sub. title:  NNWSI  Test  Plan  for  Copper  and  Copper  Base  Alloys 
!Pub. title:  Overview  Information  on  NNWSI  s Corrosion  Program 
iPub.org:  Lawrence  Livermore  National  Laboratory  iPub.no: 

MRB-0418  iPub.date:  12/10/84  !P:  9 iCit.rel:  003;005  iStart.date: 

12-06-85  {Change. date:  12-06-85 

005  • Cit:  005  {Authors:  Ballou,  Lynden  B.jMcCright,  R.  Daniel 

iSub. title:  Metal  Barrier  Testing — Objective  and  Issues  Addressed 
!Pub. title:  Overview  Information  on  NNWSI 's  Corrosion  Program 
iPub.org:  Lawrence  Livermore  National  Laboratory  5Pub.no: 

MRB-0418  ! P:  9 iCit.rel:  003; 004  iStart.date:  12-06-85 

! Chance , rlat  e:  17—06—85 

006  Cit:  006  {Authors:  Juhas,  li.  C.  ; McCr  l g.  it , R.  1).  ;l>c.  . i.c.'i,  R.  L. 

iSub. title:  Behavior  of  Stressed  and  Unstressed  304L  Specimens  in 
Tuff  Repository  Environmental  Conditions  iPub. title:  Corrosion  85 

NACE  Annual  Meeting  JPub.org:  Lawrence  Livermore  National 

Laboratory  ! Pub . sponsor : U.S.  Department  of  Energy  iSite.rel: 
Boston,  MA  iPub.no:  UCRL-91804  iContract.no:  W-7405-ENG-48 
{Other. date:  03—25—85  {P:  8 iStart.date:  10—25—85  ! Change. date: 

10-25-85 

007  Cit:  007  {Authors:  McCright,  R.  Dan i el ; Wei ss , Haskell  ! Sub . title: 

Corrosion  Behavior  of  Carbon  Steels  Under  Tuff  Repository 
Environmental  Conditions  ! Pub . title:  Materials  Research  Society 

1984  Annual  Meeting  iPub.org:  Lawrence  Livermore  National 

Laboratory  ! Pub . sponsor : U.S.  Department  of  Energy  iSite.rel: 

Boston,  MA  iPub.no:  UCRL— 90875  ! Con t r ac t . no : W— 7405— ENG— 48 

iOther.date:  11-26-84  !P:  8 iStart.date:  10-25-85  i Change. date: 

10-25-85 

008  Cit:  008  i Authors:  Bates,  John  K.  ;0versby,  Virginia  M. 

! Sub . title:  The  Behavior  of  Actinide  Containing  Glasses  During 

Gamma  Irradiation  In  a Saturated  Tuff  Environment  { Pub . title: 
Materials  Research  Society  1984  Annual  Meeting  SPub.org:  Lawrence 
Livermore  National  Laboratory  S Pub . sponsor : U.S.  Department  of 
Energy  iSite.rel:  Boston,  MA  IPub.no:  UCRL-9O018  JContract.no: 

W— 7405— ENG— 48  {Other. date:  11-26-84  iP:  8 iStart.date:  10-25-85 

! Change. date:  10—25—85 
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PAGE  2 
NW.REF  DATA 


13:31:01  06  DEC  1985 


009 


010 


01  1 


012 


013 


014 


Cit:  009  [Authors:  Fo::  , Michael  J.;McCright,  R.  Daniel 

JPub. title:  An  Overview  of  Low  Temperature  Sens i t l r a t l on 

JPub.org:  Lawrence  Livermore  National  Laboratory  ! Pub . sponsor : 

U.S.  Department  of  Energy  JPub.no:  UCRL— 15619  ! Contr act . no: 

W— 7405— ENG— 48  J Pub. page:  31  J Pub. date:  12/00/83  iP:  1 

JStart.date:  12—06—85  ! Change. date:  12-06-85 

Cit:  010  {Authors:  Glass,  Robert  S.jOverturf,  George  E.;Garnson, 

Robert  E.;McCright,  R.  Daniel  'Pub. title:  El ectrochemi cal 
Determination  of  the  Corrosion  behavior  of  Candidate  Alloys 
Proposed  for  Containment  of  High  Level  Nuclear  Waste  in  Tuff 
JPub. or q:  Lawrence  Livermore  National  Laboratory  ! Pub . sponsor : 

U.S.  Department  of  Energy  JPub.no:  UCID— 20174  J Con tract . no : 

W— 7405— ENG— 48  J Pub. page:  38  J Pub. date:  06/00/84  JP:  1 

JStart.date:  12—06—85  ! Change. date:  12-06-85  * 

Cit:  Oil  JAuthors:  Rothman,  A.  J.  JPub. title:  Potential  Corrosion 
and  Degradation  Mechanisms  of  Zircalo^  .Cladding  on  Spent  Nuclear 
Fuel  in  a Tuff  Repository  JPub.org:  llawrdnce  Livermore  National 
Laboratory  ! Pub. sponsor : U.S.  Department  of  Energy  JPub.no: 

UC ID-201 72 ; MRB— 0418  ! Contract . no:  W— 7405-ENG-48  JPub. page:  49 
JPub. date:  09/00/84  IPt  1 JStart.date:  12-06-85  ! Change. date : 

12-06-85 

Cit:  012  J Authors:  Oversby,  V.  M.;McCright,  R.  D. ; Westerman , R. 
E.;Yow,  J.  JSub. title:  Lists  of  Planned  Field  and  Laboratory 
Tests  JPub. title:  LLNL  NNWSI  Program  JPub. page:  10  JP:  9 

JStart.date:  12—06—85  J Change. date:  12-06-85 

Cit:  013  {Authors:  Weiss,  H. ;Van  Konynenburg,  R.  A.;McCright,  R. 
D.  JPub. title:  Metallurgical  Analysis  of  a 304L  Stainless  Steel 
Canister  from  the  Spent  Fuel  Test — Climax  JPub.org:  Lawrence 
Livermore  National  Laboratory  Nuclear  Waste  Management  Projects 
! Pub . sponsor : U.S.  Department  of  Energy  JPub.no:  UCID-20436 
JContract.no:  W-7405-ENG-48  JPub. page:  20  JPub. date:  04/23/85  JP: 

1 JStart.date:  12—06—85  ! Change. date:  12-06—85 

Cit:  014  {Authors:  Smith,  H.  D.jOversby,  V.  M.  JPub. title:  Spent 

Fuel  Cl  riding  Corrosion  under  Tuff  Repository  Condi t • ons- Ini  ti  ai 
Observations  JPub.org:  Lawrence  Livermore  National  Laboratory 
Nuclear  Waste  Management  Projects  ! Pub . sponsor : U.S.  Department 

of  Energy  JPub.no:  UCID-20499  ! Contr act . no:  W-7405-ENG-48 

JPub. page:  4 JPub. date:.  06/00/85  JP:  1 JStart.date:  12-06-85 

! Change. date:  12-06-85 


14  Records  Processed 
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NP^l  i 4 A iHtv.  ^-ou 


U.S.  DEPT.  OF  COMM. 

BIBLIOGRAPHIC  DATA 
SHEET  (See  instructions) 


1.  PUBLICATION  OR 
REPORT  NO. 

NBSIR  86-3363 


2.  Performing  Organ.  Report  NoJ  3.  Publication  Date 


JUNE  1986 


4.  TITLE  AND  SUBTITLE 

"An  Analysis  of  the  Requirements  for  a Computer  Assisted  Database  for  Reviews  and 
Evaluations  on  High  Level  Waste  Data" 


5.  AUTHOR(S)  C.  Interrante,  C.  Messina,  S.  Harrison,  R.  Shull,  M.  Kaufman,  U.  Bertocci, 
and  E.  Escalante. 


6.  PERFORMING  ORGANIZATION  (If  joint  or  other  than  N BS.  see  in  struction  s) 

NATIONAL  BUREAU  OF  STANDARDS 
DEPARTMENT  OF  COMMERCE 
WASHINGTON,  D.C.  20234 


7.  Contract/Grant  No. 

NRC  No.  FIN  A-4171-6 


8.  Type  of  Report  & Period  Covered 


9.  SPONSORING  ORGANIZATION  NAME  AND  COMPLETE  ADDRESS  (Street,  City.  State.  ZIP) 

U.S.  Nuclear  Regulatory  Commission  (NRC) 

Division  of  Waste  Management 
Mail  Stop  SS  965 

Washington.  D.  C.  20555 


10.  SUPPLEMENTARY  NOTES 


| | Document  describes  a computer  program;  SF-185,  FIPS  Software  Summary,  is  attached. 


11.  ABSTRACT  (A  200-word  or  less  factual  summary  of  most  significant  information . If  document  includes  a significant 

^t^^%^^{%^r"Srk’l'oSiputer-a33l3te<I  database  has  been 

initiated,  and  is  suggested  for  further  development  and  full 
implementation  for  storage  and  retrieval  of  reviews  and  evaluations 
of  high  level  waste  (HLW ) data,  composed  principally  of  pertinent 
waste- package  reports  generated  by  DOE.  Initial  suggestions  by 
materials  scientists  at  the  NBS  on  the  type  and  form  of  information 
to  be  stored  in  the  database  were  reviewed  by  NBS  computer 
scientists,  who  have  concluded  that  from  the  available  software 
packages,  Revelation  is  the  most  suitable  database  management 
system  (DBMS)  for  this  application.  Hardware  that  is  compatible 
with  existing  NRC  equipment  is  recommended.  The  format  for  storage 
and  retrieval  of  information  using  Revelation  will  require  further 
development  for  full  implementation  of  this  DBMS  for  use  with  the 
reviews  of  reports  on  the  HLW  package. 


12.  KEY  WORDS  (Six  to  twelve  entries;  alphabetical  order;  capitalize  only  proper  names;  and  separate  key  words  by  semicolon  s) 

Database;  database  management  system  (DBMS);  fields;  file;  hardware;  high  level  waste; 
microcomputer;  query;  records;  software. 


13.  AVAILABILITY 

a U nl  imited 

( F or  Official  Distribution.  Do  Not  Release  to  NTIS 

[_  J Order  From  Superintendent  of  Documents,  U.S.  Government  Printing  Office,  Washington,  D.C. 
20402. 

Q3]  Order  From  National  Technical  Information  Service  (NTIS),  Springfield,  VA.  22161 


14.  NO.  OF 

PRINTED  PAGES 

61 


15.  Price 


$11.95 
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